16 years of CVE-2008-0166 – Debian OpenSSL Bug

Post by westurner » Mon, May 13, 2024, 4:49 AM UTC

woodruffw wrote: post #16

westurner wrote: post #6

Earlier quoted context omitted.

PyPI has only implemented the "server signs whatever's uploaded with that account" part of TUF; there are no Publisher Signatures for packages uploaded to pypi (because GPG ASC support was removed from PyPI, the ad-hoc signature support was removed from wheel, and only server signatures are yet implemented). https://SLSA.dev/ recommends TUF and Sigstore.dev and trusted containers for build-signing. Someday, Twine sho…

PyPI doesn’t currently implement any part of TUF in a public facing manner, so I’m not sure where you got that from :-). There’s some limited deployment experiments with rstuf, but these are not part of any current server-side package signing scheme. PEP 740 does the rest of what you’ve described, however. And twine already has initial support for it, although it isn’t part of a release yet.

Post by b112 » Mon, May 13, 2024, 6:57 AM UTC

amaranth wrote: post #46

b112 wrote: post #34

Earlier quoted context omitted.

When the init system won't reliably start openssh, and insists the only fix is to patch, then blame the horrible init system. And that was what happened with systemd.

sd_notify is for additional (useful) functionality, it would work fine without it. You can tell because it works on arch.

Post by themoonisachees » Mon, May 13, 2024, 8:11 AM UTC

hxelk1 wrote: post #21

yjftsjthsd-h wrote: post #2

I enjoyed the... I guess "narrative Q&A" style would be a good enough way to describe it? Regardless, it's fun. > The security team at Seznam - a Czech search engine and email provider - did not believe me when I reported this issue. They assume that as they are not actively using that key (beta._domainkey.seznam.cz), that means that it cannot be used to forge emails. This is, of course, not true. Maybe consult a law…

Couple of years ago, I noticed some weird Outlook headers on our internal company e-mails and decided to take a look. It turned out our company Outlook (or Exchange? who knows) mail server was configured to relay mail through some 3rd-party SPAM filter and the SPAM filter trusted some headers which weren't stripped on ingress. So you could send an e-mail with the headers set and they would reach the SPAM filter unmod…

Post by ckastner » Mon, May 13, 2024, 3:27 PM UTC

gsich wrote: post #7

That's why you don't change upstream code without reason.

Post by cassianoleal » Mon, May 13, 2024, 4:47 PM UTC

csande17 wrote: post #38

cassianoleal wrote: post #37

Earlier quoted context omitted.

Right... I may have wrongly named Arch in my comment. Thanks for the correction. I'm curious about Arch's claim that "the build script was configured to only inject the bad code in Debian/Fedora based package build environments". Were Debian and Fedora specifically targetted, and the other distros who also got affected just happened to use similar packaging routines, or is this claim a guess?

The malicious build script included heuristics to only include the backdoor if you were building a .deb or .rpm package (the Debian and Fedora formats respectively). Other distros would have been affected if they used the same packaging setup -- Ubuntu also uses .deb, for example, because it's based on Debian. And some distros IIRC considered themselves "affected" if they ever used a malicious version of the code, ju…