should auto updaters be disabled?

should auto updaters be disabled?

[raingloom]

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.

Re: should auto updaters be disabled?

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 182 bytes --]


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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: should auto updaters be disabled?

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: should auto updaters be disabled?

[Bengt Richter]

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?

[Leo Famulari]

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.