> But, if we can't be trusted to decode base64 then how are we expected to read the rest of the rpm? That's like being too afraid to leave the house because something bad might happen.
The point was not about the correctness of our implementation of base64, but that the format should have only one canonical encoding any alternate encodings being rejected. It also makes the format more reproducible. When incorporating existing formats, it is suggested to use a format whose normal spec is strict in that regard. The reason is so that other implementations do not accidentally pick a common lax implementation, which cause different rpm implementations to accept and reject different rpms. Good formats have test suits to ensure alternative implementations reject anything besides the specified canonical encoding. The same can happen with hex: 0xabcd 0xABCD encode the same. JSON is another example that does not specify a canonical encoding and this causes security bugs regularly. One other of the advantages of only one canonical encoding is to prevent a MITM during transport of the rpm being able to modify it while the signature check would still not fail after the modification. While that may not directly pose a problem, this is a normal security precaution to be able to predict precisely what data exits on a system so that we can more easily verify it to be secure. Security bugs that are easier to exploit when arbitrary payloads are available are a regular occurrence on distributions using rpm. There are additional ways we want the rpm format to only have one encoding: forbid more than one signature with the same key; reject if signatures do not appear in a canonical sort order (e.g. sorted by key fingerprint); each dnf/zypper/etc repo should come with a list of the exact keys whose signatures all need to be verified by rpm to be present (maybe keyed on packager and vendor?); etc. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3385#issuecomment-2460265966 You are receiving this because you are subscribed to this thread. Message ID: <rpm-software-management/rpm/issues/3385/[email protected]>
_______________________________________________ Rpm-maint mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-maint
