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