On Wed, Mar 09, 2022 at 07:13:14PM +0100, Alexander Sosedkin wrote: > On Wed, Mar 9, 2022 at 7:05 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > 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. > > I don't think there is a reasonable guarantee you can use it. > It's normal for a daemon to close inherited file descriptors > and open something radically different as FD 3, right? > And then we're writing our scary messages who knows where. I presume you mean FD 2, not 3, as stderr==2. Anything is possible, but I don't think it is common for apps to connect something strange to FD 2, precisely because that is designated as stderr. There exist way too many libraries that will print error messages and warnings to stderr, for any non-trivial application to consider FD==2 safe to use for any functional purposes other than adhoc text output. Any application that wants to disconnect from its inherited stderr stream, will re-open it on /dev/null, or a text logfile, if they don't want to risk being broken by random code using stderr. Even glibc will print to stderr when it sees malloc corruption, and stuff in stderr will end up in the systemd journal for any system services. 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
