On Wed, Mar 9, 2022 at 4:40 PM Robbie Harwood <rharwood@xxxxxxxxxx> wrote: > > Alexander Sosedkin <asosedkin@xxxxxxxxxx> writes: > > > Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > >> Perhaps a useful first step is to just modify the three main > >> crypto libs (gnutls, openssl, and nss) to send a scary warnihg > >> message to stderr/syslog any time they get use of SHA1 in a > >> signature. Leave that active for a release cycle and see how > >> many bug reports we get. > > > > I left my crystal ball at home today, > > but I don't need it to say it'd be ~0 bugs filed if we log to syslog > > and ~3 if we log to stderr/stdout, all named > > "$CRYPTOLIB has no business messing up my stderr/stdout", > > It's clear you want SHA-1 gone, but the way you've written this maybe > isn't conveying what you wan, as it sounds like you're also unwilling to > process the bugs that result requesting its removal. (If you, who want > it gone, aren't willing to participate in that, why should maintainers > care?) Oh, nobody wants to go to the dentist, myself included. But it's as inevitable as it's not delegatable. Deprecating SHA-1 is no small thing, and one me could realistically do that for just a single small random thing. I can't realistically fix something big like git. I can't make DNSSEC deployments worldwide to move away from SHA-1. Besides small consultations, what I'm sure I can do is: keep postponing, raise discussions that don't convey the impact accurately, and then disable and collect my negative karma. I want to know, ultimately, how can I break it for devs but not the users so that 1. the need for it is communicated early, 2. all the relevant places are timely identified, 3. maintainers have a plenty of time to resolve it for good or opt out, 4. and the users are affected as late and as smoothly as possible. Hope these are all reasonable things to wish for. --- > As I understood the proposal, it would be for the crypto lib to log a > message like: > > [timestamp] /usr/bin/firefox used DEPRECATED SHA-1 invocation > > This is similar to what happened for /var/run: sure, it was annoying to > basically everyone involved, but the bugs also went to the relevant > packages. > > > which we'll promptly close by reverting the changes. > > I don't see why you'd do that instead of reassigning to the appropriate > packages or (better) helping them migrate. Because a cryptographic library polluting stdout/stderr is a bug! It's a bad idea on so many fronts: * for logging to be seen, it should go where the app logging goes * stderr/stdout is not always wired up to something at all * and when it is, *we break the output of the application* I think I've seen a bug when a library just opening a descriptor for its own private usage made it all go sideways, and you suggest actively interfering. --- Just for example, imagine we get a bug report: "none of my git scripts work anymore", telling us that users can no longer reliably script git because there's `/usr/libexec/git-core/git-clone used DEPRECATED SHA-1 invocation` all over the output they parse. We reassign it to git, git maintainers take their time and then decide: "we're gonna default to SHA-256 next month and disallow SHA-1 by default in 3 years because $VALID_REASONS, and for now we want $THIS_BEHAVIOUR instead". Or some other intricate, complicated and unique answer. Then what? Output of dozens of tools is still broken, users are rightfully upset, and, to add insult to injury, SHA-1 signatures still work. So, I guess, we're supposed to add an API to suppress the warning? Could be OK to use'em because it's gated behind an app opt-in or something. And then next release we disable it and then a different hundred of tools, those whose output nobody monitors or parses or even plumbs anywhere, break and we've effectively given them no forewarning. The <1% of those launching libreoffice from the terminal will have to intersect with those importing some specific format of documents to even get a slim chance of knowing why they should beware of the leopard. And it'll also break git again, giving a second round of headache to git maintainers, forcing them to roll-back interim solutions and deploy long-term ones. I think this approach manages to do it wrong twice, and that's not counting the very idea of libraries messing with stderr/stdout in the first place, which is, IMO, unthinkable. Breaking things and providing overrides to use them if really safe or necessary or opted into means interrupting maintainers just once to decide whether they override and keep using it or change to something else. Sounds much better to me. Less distractions, more consistency. Git breaks, git gets just a single prod to do the right long-term thing. Problem is, how does one stretch that in time and shield users from it. --- That being said, I'm not bent on just breaking it Michael Bay-style. On the contrary, I've started this thread precisely because I don't want to. I am open to other solutions. It's just that we shouldn't overdo them either. Like, I think Fedora SELinux denial UX is good. These don't just go to syslog or pollute stderr, they, IIRC, give desktop users instantaneous notifications that are easy to link to some specific thing that just failed on you. Doesn't mean we should write a daemon and applets for all DEs to dbus around requests to allow SHA-1 per executable path. But, IDK, if y'all tell me that waiting for another release and then disabling SHA-1 only on Tuesdays and Sundays only in rawhide for another 16 months is just what we need to soften the blow, then that's what I'm gonna roll with. As long as it's eventually done. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
