On Wed, Mar 09, 2022 at 06:45:49PM +0100, Alexander Sosedkin wrote: > On Wed, Mar 9, 2022 at 6:22 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > > > On Wed, Mar 09, 2022 at 12:14:28PM +0100, Alexander Sosedkin wrote: > > > 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", > > > which we'll promptly close by reverting the changes. > > > > Yeah, that's a little more cynically-phrased than I'd put it, but I had > > similar thoughts. > > > > But: maybe if we logged it _and_ had a tool people could run to > > look specifically for those log entries, we could do something like a Test > > Day where people could send in reports? > > On one hand, this still is a risky territory > of libraries leaning heavily into things that libraries shouldn't do > because they can never guess the weird ways they're being used > when they have existing interfaces to deny operations with some algorithms. > > On the other hand, this makes much more sense to me > than the stdout/stderr proposal. The reason I suggested stderr was because it is about the only channel you can have a reasonable guarantee of being able to use from a library that has no knowledge about its execution environment. Security policies applied to procesess (SELinux, seccomp, namespaces or containerization in general) can easily prevent ability to use journald, syslog, or opening of log files, leading to messages not being visible. At worst, with seccomp an attempt to use the blocked feature may lead to an abort of the application. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
