Re: should auto updaters be disabled?
On Sat, Feb 29, 2020 at 09:41:17PM +0100, Bengt Richter wrote: > IMO auto-update is like buying an appliance and giving > the install crew a permanent key to the kitchen door. I don't think this metaphor is wrong, but it's not very exact. Short of auditing every single line of code in a package, and skillfully detecting obfuscated malware, all of our packages may try to download and execute software at run-time. It's just the nature of computers with network access. In any case, it's extremely unlikely that a package autoupdater will work in Guix because they usually target the executable's directory and that is read-only in /gnu/store. But we should still try to disable them as a matter of Guix policy.
Re: should auto updaters be disabled?
Hi Leo, On +2020-02-28 14:47:27 -0500, Leo Famulari wrote: > On Fri, Feb 28, 2020 at 10:14:19PM +0530, Arun Isaac wrote: > > I agree that auto updaters should be disabled where applicable. But, > > ideally, like you said, this should be implemented upstream as a > > configuration option we can set at build time. > > I also agree we should make an effort to disable these features, because > they can confuse users about how to update software from Guix and also > don't offer the "binary -> source" transparency that makes Guix so > amazing. > > And I agree that it would be great if it was configurable in the > upstream source, but we could also patch it out ourselves if upstream is > not interested. > > For example, we build Syncthing with the '-no-upgrade' option which > disables auto-upgrade functionality at build time. OTTOMH reaction, offering a metaphor: IMO auto-update is like buying an appliance and giving the install crew a permanent key to the kitchen door. Would you do that in "real life" ?? (ok, who wouldn't like to live in a community where one can? :) (hm, perhaps you do, in the guix commit-privileged developer community at least :) Auto-update is handing binary patch commit privilege to an agent you chose to trust _one time_ to command your kitchen staff to do as told. No thanks, you tell me what you want them to do, and I will tell my staff/bash/readelf/etc to do it, iff I think it's ok (or my trusted security staff does). (my metaphorical "staff" of software servants -- nothing "real" ;-) I'd say an update's becoming available is an event. Maybe it could be queued for udev for configurable handling? But how to trap the event if it is arriving in an app's "ordinary" operating communications, e.g. as special packets in the streams used by an online game? BPF? Has someone developed a proposed standard/rfc for update notifications that differentiates between "you might enjoy our latest game enhancement" and a screaming "CVE-XXX: IMMEDIATELY DENY ALL, ALLOW ONLY ..." (with all the DOS threats and nuisances taken into account? Dreaming on .. but we have to dream things up before we can make them ;-) -- Regards, Bengt Richter
Re: should auto updaters be disabled?
On Fri, Feb 28, 2020 at 10:14:19PM +0530, Arun Isaac wrote: > I agree that auto updaters should be disabled where applicable. But, > ideally, like you said, this should be implemented upstream as a > configuration option we can set at build time. I also agree we should make an effort to disable these features, because they can confuse users about how to update software from Guix and also don't offer the "binary -> source" transparency that makes Guix so amazing. And I agree that it would be great if it was configurable in the upstream source, but we could also patch it out ourselves if upstream is not interested. For example, we build Syncthing with the '-no-upgrade' option which disables auto-upgrade functionality at build time. signature.asc Description: PGP signature
Re: should auto updaters be disabled?
I agree that auto updaters should be disabled where applicable. But, ideally, like you said, this should be implemented upstream as a configuration option we can set at build time. signature.asc Description: PGP signature
should auto updaters be disabled?
I've been using gPodder and Gajim for a while and right now both are notifying me about new versions, gPodder about an update to itself and Gajim about an update to OMEMO. Both the OMEMO plugin and gPodder are managed by Guix, so the builtin updaters don't really have any business mucking with my setup. I want to patch it out of gPodder, but what do others think? Would it make more sense to add a configuration option and fix it upstream? For Gajim, I'm not yet sure, since not all plugins are managed by the distro.