-
-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
devel: add reposec management command #245
base: master
Are you sure you want to change the base?
Conversation
Still a bit WIP |
devel/management/commands/reposec.py
Outdated
PackageSecurity.objects.all().delete() | ||
PackageSecurity.objects.bulk_create(results) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if it makes a big difference, but in reporead
we:
- Create ones that exist in the repo but not in the DB.
- Delete ones in the DB but not in the repo.
- Update ones that are in both.
I don't know how big the difference in performance is, but given how many packages we have, it wouldn't surprise me if it gets somewhat substantial.
If we want to do it in a similar way, I think something like this could work:
-
Before reading the repo, get a list of all package names and versions for that repo from the DB, probably in a
{pkgname: pkgver}
dict. -
Iterate over each package in the pacman repo file:
if pkgname not in pkgdict
-> add the package file path to theto_add
list.if pkgname in pkgdict
- and the version is the same, pop the package name from the package dict.
- and the version is different, leave the package in the dict so it gets deleted and also add the package file path to the
to_add
list.
-
Delete everything left in the package dict from the repo.
-
Parse all package files in the
to_add
list and add them to the repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(But if this turns out to be fairly quick on our repos as it is, feel free to ignore this.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds smart! Let me try to implement something like it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have only tried [core] and I think we should do this efficient. Also currently it removes all PackageSecurity's while it could just remove for Arch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I'm not so sure how this would work. We don't have a list of parsed packages since this implementation only adds a PackageSecurity object for once a file has a "violation". This kinda sucks for [community] which is huge. So maybe this needs some re-designing or re-use the PackageFile object.
@@ -444,6 +444,17 @@ class Meta: | |||
db_table = 'package_files' | |||
|
|||
|
|||
class PackageSecurity(models.Model): | |||
pkg = models.ForeignKey(Package, on_delete=models.CASCADE) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pkg = models.OneToOneField(Package, on_delete=models.CASCADE)
will get you a single Package.packagesecurity
attribute rather than having to deal with a list/set of one.
Looks good overall! |
Add a new command that scans pkg.tar.xz files with elf binaries in /usr/bin/ and checks for security hardening issues. This adds a new dashboard view which shows packages with these issues.
Current PR does not work on postgresql since it can't pickle the Package object due to being a memoryview in postgresql and binary in sqlite. The PR also only checks the first PIE file and not the status of all PIE files in the package. |
Show all offending files with security hardening bits missing
Add a new command that scans pkg.tar.xz files with elf binaries in
/usr/bin/ and checks for security hardening issues. This adds a new
dashboard view which shows packages with these issues.