It does not @pmatilai, but many people are uncomfortable with situations where
reporting a bug via the proper channels (public GitHub issue) means publicizing
a 0day vulnerability in their own product. They would prefer if security
problems in their product caused by upstream bugs were
And that prevents you from reporting bugs? If so, the security world is even
sadder place than I thought.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2211#discussioncomment-7506935
You are receiving this because you are
@pmatilai I, and I suspect @rhdesmond as well, are not comfortable creating a
situation where a bug is not a security vulnerability in RPM, but is a security
vulnerability in the downstream project.
--
Reply to this email directly or view it on GitHub:
Thanks for the detailed discussion all!
@DemiMarie is correct; I understand @pmatilai's concerns about intended use and
security impact. For now, we parse the db files (as other open source scanners
do) as creating a runtime is prohibitively expensive as pointed out above.
Appreciate the
A bug is a bug. The database needs to be as robust as anything else in rpm,
security impact or no.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2211#discussioncomment-7495545
You are receiving this because you are subscribed to
I think @rhdesmond is in the situation of needing to process RPM databases that
come from untrusted container images. These databases might be malicious and
might try to exploit a bug in librpm to compromise the vulnerability scanner.
Such a bug would arguably be out of scope for librpm
If you don't want to link to librpm, then other option is to use rpm cli.
Everything about the packages is accessible with rpm cli queries.
I don't understand your use-case, but if you absolutely need the package
information on file-system then create that info using rpm queries, as a part
of
Nope.
Is there a reason that using librpm is not an option? If there is, you will
need to reverse-engineer the format and keep pace with whatever librpm does.
Could you compile librpm to WebAssembly and create a new WebAssembly runtime
for each container? That could be a solution to
This restricts our use case (container vulnerability scanning): is there a
recommended way to see package information from the filesystem (like how Debian
has `/var/lib/dpkg/info/[PACKAGE].list` files)
--
Reply to this email directly or view it on GitHub:
Nothing wrong with curiosity, and this being open source, obviously nobody can
prevent people from looking.
However I have no incentive to help planned misuse, which is clearly the case
here.
The rpmdb format is undocumented because it is a private implementation detail
which rpm is free to
> The details of the database format are OFF-LIMITS TO EXTERNAL USERS!
>
> Sqlite is but one of the possible database formats. If you want to access the
> rpm database, you do so through the librpm API.
Just because one should not access the rpmdb without going through librpm does
not mean
The details of the database format are OFF-LIMITS TO EXTERNAL USERS!
If you want to access the rpm databasem, you do so through the librpm API.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2211#discussioncomment-3784801
You are
I found that, starting with RPM 4.16, RPM uses an SQLite database
([reference](https://fedoraproject.org/wiki/Changes/RPM-4.16#Detailed_Description)).
>From querying my local table, I see there are the following tables:
```
sqlite> .tables
Basenames Name Sigmd5
That's the wrong end to be looking at, totally.
'rpm -q' with
[--queryformat](https://rpm-software-management.github.io/rpm/manual/queryformat.html)
gives you access to every single bit of data in the rpmdb.
--
Reply to this email directly or view it on GitHub:
14 matches
Mail list logo
