Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Holger Wansing]

Control: notfound -1 0.57


Raphael Hertzog  wrote:
> Hi,
> 
> On Wed, 27 Jun 2018, Justin B Rye wrote:
> > _Description: Updates management on this system:
> >  Applying updates on a frequent basis is an important part of keeping the
> >  system secure.
> >  .
> >  By default, security updates are not automatically installed, as security
> >  advisories should be reviewed before manual installation of the updates
> >  using standard package management tools.
> >  .
> >  Alternatively the unattended-upgrades package can be installed, which will
> >  install security updates automatically. Note however that automatic
> >  installation of updates may occasionally cause unexpected downtime of
> >  services provided by this machine in the rare cases where the update is
> >  not fully backward-compatible, or where the security advisory requires the
> >  administrator to perform some other manual operation.
> 
> Thanks for the review. I updated the string in git. I will not upload the
> package right away, maybe later once translators had a chance to catchup
> (or maybe someone else will decide to upload before me).

This has been committed in
https://salsa.debian.org/installer-team/pkgsel/commit/2b9b594855a409fa6d03f259ccca4b1a1bd4727b
however this bug was not mentioned in the changelog, and therefore not closed.

Tagging this bug as fixed in version 0.57


Holger



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Hi,

On Wed, 27 Jun 2018, Justin B Rye wrote:
> _Description: Updates management on this system:
>  Applying updates on a frequent basis is an important part of keeping the
>  system secure.
>  .
>  By default, security updates are not automatically installed, as security
>  advisories should be reviewed before manual installation of the updates
>  using standard package management tools.
>  .
>  Alternatively the unattended-upgrades package can be installed, which will
>  install security updates automatically. Note however that automatic
>  installation of updates may occasionally cause unexpected downtime of
>  services provided by this machine in the rare cases where the update is
>  not fully backward-compatible, or where the security advisory requires the
>  administrator to perform some other manual operation.

Thanks for the review. I updated the string in git. I will not upload the
package right away, maybe later once translators had a chance to catchup
(or maybe someone else will decide to upload before me).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Justin B Rye]

Raphael Hertzog wrote:
> _Description: Updates management on this system:
>  Applying updates on a frequent basis is an important part of keeping the
>  system secure.
>  .
>  By default, security updates are not automatically installed as security
>  advisories should be reviewed before installation of the updates using
>  standard package management tools.

This would benefit from an extra comma before "as".  I'd like to make
it clear that it's the installing rather than the reviewing that's
done "using standard package management tools", but I don't think a
comma helps with that... maybe instead it should have an explicitly
contrasting "before manual installation [...]"?

>  .
>  Alternatively the unattended-upgrades package can be installed, it will
 
Comma-spliced sentences; make the second one a subclause, "which will
install".

>  install security updates automatically. Note however that automatic
>  installation of updates may occasionally cause unexpected downtime of
>  services provided by this machine in the rare cases where the update is
>  not fully backwards compatible or when the security advisory requires the
>  administrator to perform some other manual operation.

Another complicated unpunctuated sentence.  Make the two kinds of
"rare case" more parallel - instead of a "where" and a "when", make
them both "where"s.

"Backwards compatible" is slightly commoner in en-GB and "backward
compatible" in en-US; for debconf prompts the d-l-e standard is to
prefer en-US.  Either way, a hyphen would help.

So:


_Description: Updates management on this system:
 Applying updates on a frequent basis is an important part of keeping the
 system secure.
 .
 By default, security updates are not automatically installed, as security
 advisories should be reviewed before manual installation of the updates
 using standard package management tools.
 .
 Alternatively the unattended-upgrades package can be installed, which will
 install security updates automatically. Note however that automatic
 installation of updates may occasionally cause unexpected downtime of
 services provided by this machine in the rare cases where the update is
 not fully backward-compatible, or where the security advisory requires the
 administrator to perform some other manual operation.


-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Hi,

On Tue, 26 Jun 2018, Wouter Verhelst wrote:
> I think it makes sense to explain in a bit more detail why that may not
> be a good idea:

Ok.

On Tue, 26 Jun 2018, Cyril Brulebois wrote:
> I think it really should get reviewed through the usual channel
> (debian-l10n-english@ if memory serves, but don't trust me on this), so
> that we avoid common errors.

Ok.

I'm ccing debian-l10n-engl...@lists.debian.org to have their review.
Here's the updated string that I'm now proposing based on the early
feedback:

_Description: Updates management on this system:
 Applying updates on a frequent basis is an important part of keeping the
 system secure.
 .
 By default, security updates are not automatically installed as security
 advisories should be reviewed before installation of the updates using
 standard package management tools.
 .
 Alternatively the unattended-upgrades package can be installed, it will
 install security updates automatically. Note however that automatic
 installation of updates may occasionally cause unexpected downtime of
 services provided by this machine in the rare cases where the update is
 not fully backwards compatible or when the security advisory requires the
 administrator to perform some other manual operation.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):

> The use of “you” seems to be one of the common errors I mentioned above.
> We tend to avoid pointing fingers at users.
> 
> Hrm. Grepping across our packages' templates, I see a lot of “you”s so I
> might just be misremembering. Or maybe we've tried hard not to introduce
> new occurrences while not actively fixing pre-existing entries.


The use of "you" is, I would say, tolerated. What we tried to avoid
(at least when I was a PITA for people wanting to introduce new
templates) was what I called "personnalization" of the computer :
"your machine", for instance. Everything that seems to impply that the
machine being installed belongs to the person who is installing it.

Addressing the user has been accepted : "you should do this", "you
need to do thaat".

In this case, I would try avoiding to imply that the person
installingn the machine will be the person who has to review security
chnges when they happen, so I'd probably use the passive form
"Security updates should be reviewed before they are applied"..os
something like this.

But you're right : we used debian-l10n-english for reviewing
templates. If someone is still alive there, (s)he may help.




signature.asc
Description: PGP signature

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Cyril Brulebois]

Hi Raphaël,

Raphael Hertzog  (2018-06-26):
> I reverted the change in git:
> https://salsa.debian.org/installer-team/pkgsel/commit/2b9b594855a409fa6d03f259ccca4b1a1bd4727b

ACK, thanks for the notice.

> I haven't uploaded the package yet. I had to reword the debconf
> template.  Is the modified template fine?

I think it really should get reviewed through the usual channel
(debian-l10n-english@ if memory serves, but don't trust me on this), so
that we avoid common errors.

> _Description: Updates management on this system:
>  Applying updates on a frequent basis is an important part of keeping the
>  system secure.
>  .
>  By default, security updates are not automatically installed as you
>  have to review the security advisories before installing the updates
>  using standard package management tools. Alternatively you can install
>  the unattended-upgrades package which will install security updates
>  automatically.

The use of “you” seems to be one of the common errors I mentioned above.
We tend to avoid pointing fingers at users.

Hrm. Grepping across our packages' templates, I see a lot of “you”s so I
might just be misremembering. Or maybe we've tried hard not to introduce
new occurrences while not actively fixing pre-existing entries.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Wouter Verhelst]

On Tue, Jun 26, 2018 at 06:17:31PM +0200, Raphael Hertzog wrote:
> Hello,
> 
> On Mon, 28 May 2018, Cyril Brulebois wrote:
> > debian-boot@: the requested revert looks fine to me, bonus points if it
> > comes with a (short) summary of these reasons in changelog, so that they
> > can be emphasized in the release announcement. :)
> 
> I reverted the change in git:
> https://salsa.debian.org/installer-team/pkgsel/commit/2b9b594855a409fa6d03f259ccca4b1a1bd4727b
> 
> I haven't uploaded the package yet. I had to reword the debconf template.
> Is the modified template fine?
> 
> _Description: Updates management on this system:
>  Applying updates on a frequent basis is an important part of keeping the
>  system secure.
>  .
>  By default, security updates are not automatically installed as you
>  have to review the security advisories before installing the updates
>  using standard package management tools. Alternatively you can install
>  the unattended-upgrades package which will install security updates
>  automatically.

I think it makes sense to explain in a bit more detail why that may not
be a good idea:

"(...) security updates automatically. However, note that updates, even
to stable, are not guaranteed to be zero maintenance, and as such
automatic updates through unattended-upgrades may occasionally cause
downtime of services provided by this machine."

...or something along those lines.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Hello,

On Mon, 28 May 2018, Cyril Brulebois wrote:
> debian-boot@: the requested revert looks fine to me, bonus points if it
> comes with a (short) summary of these reasons in changelog, so that they
> can be emphasized in the release announcement. :)

I reverted the change in git:
https://salsa.debian.org/installer-team/pkgsel/commit/2b9b594855a409fa6d03f259ccca4b1a1bd4727b

I haven't uploaded the package yet. I had to reword the debconf template.
Is the modified template fine?

_Description: Updates management on this system:
 Applying updates on a frequent basis is an important part of keeping the
 system secure.
 .
 By default, security updates are not automatically installed as you
 have to review the security advisories before installing the updates
 using standard package management tools. Alternatively you can install
 the unattended-upgrades package which will install security updates
 automatically.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Cyril Brulebois]

Hi Moritz,

Moritz Mühlenhoff  (2018-05-27):
> Sorry for the late reply, busy and backlogged in my inbox.

No worries, I know the feeling; and thanks for the detailed answer!

Replying only briefly (for similar reasons):

> u-u is also very rudimentary. It doesn't support service restarts
> e.g., so installing an openssl update is pretty pointless as it
> doesn't even attempt to warn/act on library restarts.
> 
> It's also very brittle, only a few days ago I had to fix a stretch
> system where it uninstalled virtually all KDE packages after
> installing the VLC update (which installed a new version of libvlccore
> and all went kaboom).
> 
> All this crap falls back to the security team, because people think
> our update broke the system. Or stuff like
> https://lists.debian.org/debian-security/2018/05/msg00011.html
> 
> u-u breaks stuff (and would even more so if installed by default on
> servers, where it will cause unpredictable server downtimes during
> restarts etc.) and Debian should not be broken by default.
> 
> If userse make a concious decision to accept the consequences of
> unattended-upgrades, then they can install it explicitly and have to
> deal with the fallout, but it must not be part of a default
> installation.
> 
> If this had been proposed to t...@security.debian.org before making
> the change we would have objected immediately as we are the ones
> primarily affected.  We can't sensibly follow all the
> discussions/developments made in Debian, it's far too big. (And being
> in the security team is already so time-demanding that it leaves
> little for other Debian work anyway).

Sorry about the fallouts. I can't say for sure but ISTR I only found out
about this change when preparing a release announcement, even if there
were prior discussions in other channels (debian-devel@). The security
team should have been looped in, and I'm sorry I didn't think of it at
the time, even after the fact (= right after a D-I Alpha was published).

debian-boot@: the requested revert looks fine to me, bonus points if it
comes with a (short) summary of these reasons in changelog, so that they
can be emphasized in the release announcement. :)

Thanks to everyone involved.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Moritz Mühlenhoff]

On Fri, May 18, 2018 at 11:53:42PM +0200, Cyril Brulebois wrote:

Sorry for the late reply, busy and backlogged in my inbox.

> > > That's pointless until testing becomes stable and by then it's too
> > > late, this needs to be disabled now. 
> 
> Do you have minutes/rationales or something that can be pointed to?
> Reverting with just “security team says so” wouldn't be too good.

unattended-upgrades is a crude hack at best and _not_ suitable for a default
installation. There are selected scenarios where it might be useful (such as
a staging or test environment), but there will always be security updates which
are not sufficiently resolved by simply installing a package or which will
even break installations if no additional changes are made. The only supported
way to deploy a security update issued by the Debian Security Team is to follow
our advisories (which will provide instructions if an update requires subsequent
steps) and test it before it gets rolled out to additional machines. While we
have a very low regression rate, those are inevitable to a certain extent and
there's always stuff you cannot test/cover (local packages, cruft from previous
releases).

u-u is also very rudimentary. It doesn't support service restarts e.g., so
installing an openssl update is pretty pointless as it doesn't even attempt
to warn/act on library restarts.

It's also very brittle, only a few days ago I had to fix a stretch system where
it uninstalled virtually all KDE packages after installing the VLC update (which
installed a new version of libvlccore and all went kaboom).

All this crap falls back to the security team, because people think our update
broke the system. Or stuff like 
https://lists.debian.org/debian-security/2018/05/msg00011.html

u-u breaks stuff (and would even more so if installed by default on servers, 
where it
will cause unpredictable server downtimes during restarts etc.) and Debian 
should
not be broken by default.

If userse make a concious decision to accept the consequences of 
unattended-upgrades,
then they can install it explicitly and have to deal with the fallout, but it 
must not
be part of a default installation.

If this had been proposed to t...@security.debian.org before making the
change we would have objected immediately as we are the ones primarily affected.
We can't sensibly follow all the discussions/developments made in Debian, it's
far too big. (And being in the security team is already so time-demanding that 
it
leaves little for other Debian work anyway).

Cheers,
Moritz

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Cyril Brulebois]

Hi,

Moritz Mühlenhoff  (2018-05-18):
> retitle 875858 Revert default installation of unattended-upgrades
> thanks
> 
> [Resending since the earlier unarchive wasn't effective yet, so the
>  followup got lost]
> 
> Moritz Mühlenhoff wrote:
> > On Thu, Jan 04, 2018 at 01:31:25PM +0100, Raphael Hertzog wrote:
> > > OK, putting team@security in copy now. I would like to hear the opinion of
> > > other team members.
> > 
> > We've discussed this at the Security Team sprint and we don't want to
> > see this enabled by default.
> > 
> > > For the actual decision of reverting this default value, IMO we should
> > > wait until later in the buster cycle, just to see if your concerns about
> > > unattended-upgrades are fixed and to see how this works out in practice
> > > (although the lack of security updates for testing makes it a bit
> > > pointless as an experiment).
> > 
> > That's pointless until testing becomes stable and by then it's too
> > late, this needs to be disabled now. 

Do you have minutes/rationales or something that can be pointed to?
Reverting with just “security team says so” wouldn't be too good.

Thanks already.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Moritz Mühlenhoff]

retitle 875858 Revert default installation of unattended-upgrades
thanks

[Resending since the earlier unarchive wasn't effective yet, so the
 followup got lost]

Moritz Mühlenhoff wrote:
> On Thu, Jan 04, 2018 at 01:31:25PM +0100, Raphael Hertzog wrote:
> > OK, putting team@security in copy now. I would like to hear the opinion of
> > other team members.
> 
> We've discussed this at the Security Team sprint and we don't want to
> see this enabled by default.
> 
> > For the actual decision of reverting this default value, IMO we should
> > wait until later in the buster cycle, just to see if your concerns about
> > unattended-upgrades are fixed and to see how this works out in practice
> > (although the lack of security updates for testing makes it a bit
> > pointless as an experiment).
> 
> That's pointless until testing becomes stable and by then it's too
> late, this needs to be disabled now. 

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

On Tue, 02 Jan 2018, Moritz Mühlenhoff wrote:
> Even more reason not to enable it if desktops are already catered for.

There's more than GNOME in Debian.

> > Right, there are cases where a service restart is required. There are also
> > many cases where it's not at all required because the library is only used
> > by short-lived processes. And there are security updates of applications
> > too. In all those cases, there are security benefits.
> 
> But it also provides a completely false sense of security as in "Debian takes
> care of this by default, no need to bother".

I think we can document the limitations of our current update procedure.

> > Or we could have a way to tag such breaking upgrades and teach
> > unattended-upgrades to skip them? And the unattended upgrades would notify
> > the admin about the need to manually upgrade?
> 
> Possibly, yes.

Can you file a wishlist bug suggesting this so that a more concrete
proposal can be hashed out with the unattended-upgrades maintainers ?

> > In any case, I'm not convinced that not installing updates and keeping a
> > running vulnerable service is better than breaking the service and letting
> > the admin fix it. If the admin is really concerned with the occasional
> > breakage then he will use another process and deinstall
> > unattended-upgrades.
> 
> unattended-upgrades is a crude hack at best, it's _not_ suitable for a default
> installation. There might be scenarios where it's fine to apply (e.g.
> in some test/staging environment or a desktop where breakage is acceptable and
> where people can install unattended-upgrades), but not for Debian 
> installations
> per se.

Besides service reloading, and a way to skip breaking upgrades, what else
would be needed so that you don't call it a "crude hack"?

> It also totally changes the dynamics from "Debian releases updates and it's
> my responsibility to test and deploy them within the parameters of my setup"
> to "updates are installed by default and the inevitable random regression 
> broke our systems, it's Debian's fault".

I don't see the relationship. This is really a question of documentation
and of setting the expectations straight.

> Providing security support for the biggest distro on a volunteer basis
> is complex enough, no need for unattended-upgrades to interfere further.

We certainly don't want to make it more complex for you, we just want more
people to benefit from your work, all those that are not paying attention
at all on the cloud servers that they brought up and then forgot about
when they were doing what they were supposed to do.

> > Because it was largely discussed on debian-devel already and I was not
> > aware that the security team had any reservation about this. I would
> > rather that we keep going and improve where needed instead of reverting
> > the change.
> 
> Random mailing discussions are not a useful consensus building mechanism,
> most of us don't follow them on a timely basis. This primarily affects the
> Security Team and such changes need to be brought to the attention of
> t...@security.debian.org

OK, putting team@security in copy now. I would like to hear the opinion of
other team members. Do you all agree with what Moritz said? Do you expect
more work for the security team just because we enable unattended-upgrades
by default? What kind of problems do you foresee?

At this point, if you all agree that this needs to be reverted, then you
will have to open a new bug report making your case. It would be even
better if you filed bugs against unattended-upgrades so that there is a
chance that the tool grows the missing features.

For the actual decision of reverting this default value, IMO we should
wait until later in the buster cycle, just to see if your concerns about
unattended-upgrades are fixed and to see how this works out in practice
(although the lack of security updates for testing makes it a bit
pointless as an experiment).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Moritz Mühlenhoff]

Hi,

Sorry for the late reply, busy over the holiday season.

On Mon, Dec 18, 2017 at 12:12:08PM +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Sun, 17 Dec 2017, Moritz Mühlenhoff wrote:
> > unattended-upgrades are not an appropriate default. It's okay for a desktop
> > system which gets powered down daily, so you can add it to tasksel lists for
> > desktop roles, but not enable it by default for servers.
> 
> I think it's not really useful for GNOME since it already has the required
> plumbing to install updates when you shut down.

Even more reason not to enable it if desktops are already catered for.

> > - It does not handle restarts. If you upgrade OpenSSL (or any library) with
> > it, all your services will be left vulnerable until restarted. It will
> > give people a warm fuzzy feeling, but not any actual security benefit.
> 
> Right, there are cases where a service restart is required. There are also
> many cases where it's not at all required because the library is only used
> by short-lived processes. And there are security updates of applications
> too. In all those cases, there are security benefits.

But it also provides a completely false sense of security as in "Debian takes
care of this by default, no need to bother".

> > - We do need to make the occasional breaking change where people have to
> > modify configuration settings or perform additional manual steps. With
> > unattended-upgrades people don't have a chance to intervene. And if their
> > setups break, we're the ones who get blamed.
> 
> If this is a real concern, we can maybe have some environment variable
> indicating that the upgrade is automatic without any human watching it and
> have the preinst fail?
> 
> Or we could have a way to tag such breaking upgrades and teach
> unattended-upgrades to skip them? And the unattended upgrades would notify
> the admin about the need to manually upgrade?

Possibly, yes.

> In any case, I'm not convinced that not installing updates and keeping a
> running vulnerable service is better than breaking the service and letting
> the admin fix it. If the admin is really concerned with the occasional
> breakage then he will use another process and deinstall
> unattended-upgrades.

unattended-upgrades is a crude hack at best, it's _not_ suitable for a default
installation. There might be scenarios where it's fine to apply (e.g.
in some test/staging environment or a desktop where breakage is acceptable and
where people can install unattended-upgrades), but not for Debian installations
per se.

It also totally changes the dynamics from "Debian releases updates and it's
my responsibility to test and deploy them within the parameters of my setup"
to "updates are installed by default and the inevitable random regression 
broke our systems, it's Debian's fault".

Providing security support for the biggest distro on a volunteer basis
is complex enough, no need for unattended-upgrades to interfere further.

> > Why was this change made without contacting t...@security.debian.org (as
> > the ones who are affected the most)?
> 
> Because it was largely discussed on debian-devel already and I was not
> aware that the security team had any reservation about this. I would
> rather that we keep going and improve where needed instead of reverting
> the change.

Random mailing discussions are not a useful consensus building mechanism,
most of us don't follow them on a timely basis. This primarily affects the
Security Team and such changes need to be brought to the attention of
t...@security.debian.org

Cheers,
Moritz

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Hi,

On Sun, 17 Dec 2017, Moritz Mühlenhoff wrote:
> unattended-upgrades are not an appropriate default. It's okay for a desktop
> system which gets powered down daily, so you can add it to tasksel lists for
> desktop roles, but not enable it by default for servers.

I think it's not really useful for GNOME since it already has the required
plumbing to install updates when you shut down.

> - It does not handle restarts. If you upgrade OpenSSL (or any library) with
> it, all your services will be left vulnerable until restarted. It will
> give people a warm fuzzy feeling, but not any actual security benefit.

Right, there are cases where a service restart is required. There are also
many cases where it's not at all required because the library is only used
by short-lived processes. And there are security updates of applications
too. In all those cases, there are security benefits.

> - We do need to make the occasional breaking change where people have to
> modify configuration settings or perform additional manual steps. With
> unattended-upgrades people don't have a chance to intervene. And if their
> setups break, we're the ones who get blamed.

If this is a real concern, we can maybe have some environment variable
indicating that the upgrade is automatic without any human watching it and
have the preinst fail?

Or we could have a way to tag such breaking upgrades and teach
unattended-upgrades to skip them? And the unattended upgrades would notify
the admin about the need to manually upgrade?

In any case, I'm not convinced that not installing updates and keeping a
running vulnerable service is better than breaking the service and letting
the admin fix it. If the admin is really concerned with the occasional
breakage then he will use another process and deinstall
unattended-upgrades.

> Why was this change made without contacting t...@security.debian.org (as
> the ones who are affected the most)?

Because it was largely discussed on debian-devel already and I was not
aware that the security team had any reservation about this. I would
rather that we keep going and improve where needed instead of reverting
the change.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Moritz Mühlenhoff]

On Tue, Dec 12, 2017 at 09:23:50AM +0100, Raphael Hertzog wrote:
> > But my experience has mostly been with regular package updates.  I haven't
> > focused much on security updates.  Can security updates be applied with out
> > generating dependency chains and their updates?
> 
> Yes. I am seriously doubting that you ever applied any security update on
> a server running Debian stable by yourself. That's the point of security
> updates on stable releases, they fix only the security vulnerabilities but
> do not introduce functional changes and have a limited risk of breakage.

unattended-upgrades are not an appropriate default. It's okay for a desktop
system which gets powered down daily, so you can add it to tasksel lists for
desktop roles, but not enable it by default for servers.

- It does not handle restarts. If you upgrade OpenSSL (or any library) with
it, all your services will be left vulnerable until restarted. It will
give people a warm fuzzy feeling, but not any actual security benefit.
- We do need to make the occasional breaking change where people have to
modify configuration settings or perform additional manual steps. With
unattended-upgrades people don't have a chance to intervene. And if their
setups break, we're the ones who get blamed.

Why was this change made without contacting t...@security.debian.org (as
the ones who are affected the most)?

Cheers,
Moritz

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Wouter Verhelst]

On Mon, Dec 11, 2017 at 10:55:20PM -0400, Raymond Burkholder wrote:
> On 12/11/2017 11:51 AM, Steve McIntyre wrote:
> > On Mon, Dec 11, 2017 at 04:41:38PM +0100, Wouter Verhelst wrote:
> > > On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:
> > > > > 
> > > > > I think its totally adequate to assume people want automatic security
> > > > > updates, on all kinds of systems, unless they opt out.
> > > > 
> > > > Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.
> > > 
> > > Are you advocating for having servers with known-security-buggy services
> > > running all over the Internet, then?
> > 
> > That's the point here, yes. We've had this discussion already several
> > times, and it was triggered by needs/desires of cloud providers. As a
> > *default*, it makes sense to have automated security updates to cover
> > the users who don't care, or don't know any better. Users with more
> > knowledge and hard requirements about downtime etc. should already be
> > managing this.
> 
> I think I got thrown off by the title 'unattended upgrades'.  If this is
> limited to security updates,

It is limited to updates *within the release you're running*. That is,
it won't change your sources.list, but it will upgrade packages that
you've already got installed.

The largest part of that is "security updates", yes, but there will
sometimes also be non-security updates of high-severity bugs in there
(for an example of such a non-security bug that I worked on a while
back, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787398).

> I am more for it, but still scared of it.

It's only meant to be a default that can be changed. If you don't like
it, as an informed user, you can switch it off (and we would encourage
you to do so if you have other ways of keeping your systems up-to-date
and secure).

It's only meant to help those who don't care about manually applying
updates.

> Security updates tend to come in packages which have already have had other
> regular patches applied (except, I suppose in 'stable' versions), and
> sometimes one can get caught in functional changes.
> 
> I guess that is my greatest fear,  breakages due to updates.

Please educate yourself on what Debian allows for stable updates
(answer: very very very little)

> But my experience has mostly been with regular package updates.  I haven't
> focused much on security updates.  Can security updates be applied with out
> generating dependency chains and their updates?

Yes, in general. Debian prefers to backport security fixes rather than
upgrading to "the newest version", whatever that is. However, sometimes
that isn't possible (e.g., for webbrowsers), and then we do
(reluctantly) upgrade to more recent upstream versions.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Hello,

On Mon, 11 Dec 2017, Raymond Burkholder wrote:
> I think I got thrown off by the title 'unattended upgrades'.  If this is
> limited to security updates, I am more for it, but still scared of it.

Maybe you should document yourself before commenting and sharing such a
strongly worded opinion. Have a look at the unattended-upgrades package
and what it does.

> But my experience has mostly been with regular package updates.  I haven't
> focused much on security updates.  Can security updates be applied with out
> generating dependency chains and their updates?

Yes. I am seriously doubting that you ever applied any security update on
a server running Debian stable by yourself. That's the point of security
updates on stable releases, they fix only the security vulnerabilities but
do not introduce functional changes and have a limited risk of breakage.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

On 12/11/2017 11:51 AM, Steve McIntyre wrote:

On Mon, Dec 11, 2017 at 04:41:38PM +0100, Wouter Verhelst wrote:

On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:


I think its totally adequate to assume people want automatic security
updates, on all kinds of systems, unless they opt out.


Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.


Are you advocating for having servers with known-security-buggy services
running all over the Internet, then?


That's the point here, yes. We've had this discussion already several
times, and it was triggered by needs/desires of cloud providers. As a
*default*, it makes sense to have automated security updates to cover
the users who don't care, or don't know any better. Users with more
knowledge and hard requirements about downtime etc. should already be
managing this.


I think I got thrown off by the title 'unattended upgrades'.  If this is 
limited to security updates, I am more for it, but still scared of it.


Security updates tend to come in packages which have already have had 
other regular patches applied (except, I suppose in 'stable' versions), 
and sometimes one can get caught in functional changes.


I guess that is my greatest fear,  breakages due to updates.

But my experience has mostly been with regular package updates.  I 
haven't focused much on security updates.  Can security updates be 
applied with out generating dependency chains and their updates?




--
Raymond Burkholder
r...@oneunified.net
https://blog.raymond.burkholder.net

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

You can tell me if I am 'beating a dead horse' but for the sake of 
argument, let us see where this goes 


On 12/11/2017 11:41 AM, Wouter Verhelst wrote:

On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:


I think its totally adequate to assume people want automatic security
updates, on all kinds of systems, unless they opt out.


Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.


Are you advocating for having servers with known-security-buggy services
running all over the Internet, then?


hmm, almost like being asked to answer the question 'have you stopped 
beating your  yet?'.  One can't win by answering.


But things depend:

* servers can't can't be rebooted willy nilly

* when a package is updated with files open, the active process gets the 
existing files, and new processes get the new files, and is the patched 
package functional simultaneously in both activities (file formats, 
database schemas, )?


* does the patch introduce a functional change which may break 
operations (inverting logic on something, removing a flag, ... ) which 
breaks dependencies elsewhere





For my infrastructure, updates, of what ever kind, need to be
incorporated into the test/build/roll-out cycle.


If you have a test/build/roll-out cycle, then you presumably have a
local mirror (and if you don't, well, why not?) Just make sure your
servers only pull from that local mirror, and you're done.


I do have the local mirror (more like a package proxy at the moment),

But this mechansim does require a certain finesse.  running apt update 
&& apt upgrade against that local mirror/proxy may cause it to update to 
versions not quite desired, which leads to a specialized mirror with 
pre-cleared packages, but, well, I'm not that sophisticated quite yet.




[...]

So, as an accommodation,  a flag in the preseed mechanism to
enable/disable would be helpful.  But would need to be exposed in
maybe the expert mode menus, which I think was already mentioned.


What Raphaël was proposing is exactly that, yes.

Also, there is absolutely *no* technical difference between "the preseed
mechanism", "a low-priority debconf question", and "something in the
expert mode menus". None. Zero. Zilch.



--
Raymond Burkholder
r...@oneunified.net
https://blog.raymond.burkholder.net

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Brian Potkin]

On Mon 11 Dec 2017 at 17:46:44 +, Steve McIntyre wrote:

> On Mon, Dec 11, 2017 at 06:20:55PM +0100, Christian PERRIER wrote:
> >Quoting Raymond Burkholder (r...@oneunified.net):
> >> > > So, as an accommodation,  a flag in the preseed mechanism to
> >> > enable/disable would be helpful.  
> >> > 
> >> > You mean something like:
> >> > 
> >> > Template: pkgsel/update-policy
> >> > Type: select
> >> > Default: unattended-upgrades
> >> > 
> >> > pkgsel/update-policy=none thus seem the perfect preseed choice for your
> >> > use case.
> >> > 
> >> 
> >> Yes, thank you, that works for me.
> >> 
> >> Is there a dictionary somewhere where I can look these things up?  From
> >> where did you get your Template extract?
> >
> >No, there is no such dictionary. Sadly, documenting all possible
> >presseding options really lacks a dedicated effort. There was one, in
> >the past, when the D-I team was much bigger, and, still the
> >Installation Guiide does document the most important options, but
> >those that have been "recently" added ("recentlly" means "last years")
> >shoudl be added there.
> >
> >I got the template extractfrom the package source itself (pkgsel
> >package, here).
> 
> As a trivial lookup, sources.debian.net will show all the template
> files in Debian:
> 
>   
> https://codesearch.debian.net/search?q=Template%3A+path%3Adebian%2F.*.template
> 
> but it's a large set in just sid: ("761 files grepped (4453 results)")...

apt-extracttemplates is a useful utility in apt-utils. For a set of
udebs

  apt-extracttemplates -t $PWD *.udeb

will extract any templates files in the udebs.

  rm *.config.*

deletes unneeded files.

All that is needed for a "dictionary" is to tidy up the templates files.
Perhaps

  
https://wiki.debian.org/DebianInstaller/Preseed#Preseeding_and_the_installer.27s_debconf_templates

helps?

-- 
Brian.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Steve McIntyre]

On Mon, Dec 11, 2017 at 06:20:55PM +0100, Christian PERRIER wrote:
>Quoting Raymond Burkholder (r...@oneunified.net):
>> > > So, as an accommodation,  a flag in the preseed mechanism to
>> > enable/disable would be helpful.  
>> > 
>> > You mean something like:
>> > 
>> > Template: pkgsel/update-policy
>> > Type: select
>> > Default: unattended-upgrades
>> > 
>> > pkgsel/update-policy=none thus seem the perfect preseed choice for your
>> > use case.
>> > 
>> 
>> Yes, thank you, that works for me.
>> 
>> Is there a dictionary somewhere where I can look these things up?  From
>> where did you get your Template extract?
>
>No, there is no such dictionary. Sadly, documenting all possible
>presseding options really lacks a dedicated effort. There was one, in
>the past, when the D-I team was much bigger, and, still the
>Installation Guiide does document the most important options, but
>those that have been "recently" added ("recentlly" means "last years")
>shoudl be added there.
>
>I got the template extractfrom the package source itself (pkgsel
>package, here).

As a trivial lookup, sources.debian.net will show all the template
files in Debian:

  https://codesearch.debian.net/search?q=Template%3A+path%3Adebian%2F.*.template

but it's a large set in just sid: ("761 files grepped (4453 results)")...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Christian PERRIER]

Quoting Raymond Burkholder (r...@oneunified.net):
> > > So, as an accommodation,  a flag in the preseed mechanism to
> > enable/disable would be helpful.  
> > 
> > You mean something like:
> > 
> > Template: pkgsel/update-policy
> > Type: select
> > Default: unattended-upgrades
> > 
> > pkgsel/update-policy=none thus seem the perfect preseed choice for your
> > use case.
> > 
> 
> Yes, thank you, that works for me.
> 
> Is there a dictionary somewhere where I can look these things up?  From
> where did you get your Template extract?

No, there is no such dictionary. Sadly, documenting all possible
presseding options really lacks a dedicated effort. There was one, in
the past, when the D-I team was much bigger, and, still the
Installation Guiide does document the most important options, but
those that have been "recently" added ("recentlly" means "last years")
shoudl be added there.

I got the template extractfrom the package source itself (pkgsel
package, here).




signature.asc
Description: PGP signature

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Steve McIntyre]

On Mon, Dec 11, 2017 at 04:41:38PM +0100, Wouter Verhelst wrote:
>On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:
>> > 
>> > I think its totally adequate to assume people want automatic security
>> > updates, on all kinds of systems, unless they opt out.
>> 
>> Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.
>
>Are you advocating for having servers with known-security-buggy services
>running all over the Internet, then?

That's the point here, yes. We've had this discussion already several
times, and it was triggered by needs/desires of cloud providers. As a
*default*, it makes sense to have automated security updates to cover
the users who don't care, or don't know any better. Users with more
knowledge and hard requirements about downtime etc. should already be
managing this.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
We don't need no education.
We don't need no thought control.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Wouter Verhelst]

On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:
> > 
> > I think its totally adequate to assume people want automatic security
> > updates, on all kinds of systems, unless they opt out.
> 
> Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.

Are you advocating for having servers with known-security-buggy services
running all over the Internet, then?

> For my infrastructure, updates, of what ever kind, need to be
> incorporated into the test/build/roll-out cycle.

If you have a test/build/roll-out cycle, then you presumably have a
local mirror (and if you don't, well, why not?) Just make sure your
servers only pull from that local mirror, and you're done.

[...]
> So, as an accommodation,  a flag in the preseed mechanism to
> enable/disable would be helpful.  But would need to be exposed in
> maybe the expert mode menus, which I think was already mentioned.

What Raphaël was proposing is exactly that, yes.

Also, there is absolutely *no* technical difference between "the preseed
mechanism", "a low-priority debconf question", and "something in the
expert mode menus". None. Zero. Zilch.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

> > So, as an accommodation,  a flag in the preseed mechanism to
> enable/disable would be helpful.  
> 
> You mean something like:
> 
> Template: pkgsel/update-policy
> Type: select
> Default: unattended-upgrades
> 
> pkgsel/update-policy=none thus seem the perfect preseed choice for your
> use case.
> 

Yes, thank you, that works for me.

Is there a dictionary somewhere where I can look these things up?  From
where did you get your Template extract?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Christian PERRIER]

Quoting Raymond Burkholder (r...@oneunified.net):
> > 
> > I think its totally adequate to assume people want automatic security
> > updates, on all kinds of systems, unless they opt out.
> 
> Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.
> 
> For my infrastructure, updates, of what ever kind, need to be incorporated 
> into the test/build/roll-out cycle.
> 
> Unless I misunderstand the intent of this thread.
> 
> So, as an accommodation,  a flag in the preseed mechanism to enable/disable 
> would be helpful.  But would need to be exposed in maybe the expert mode 
> menus, which I think was already mentioned.


You mean something like:

emplate: pkgsel/update-policy
Type: select
Default: unattended-upgrades
Choices-C: none, unattended-upgrades
__Choices: No automatic updates, Install security updates automatically
_Description: Updates management on this system:
 Applying updates on a frequent basis is an important part of keeping the
 system secure.
 .
 By default, security updates are automatically installed by the
 unattended-upgrades package. Alternatively, you can opt-out from
 this system and apply updates manually using standard package management
 tools.


pkgsel/update-policy=none thus seem the perfect preseed choice for
your use case.




signature.asc
Description: PGP signature

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

> 
> I think its totally adequate to assume people want automatic security
> updates, on all kinds of systems, unless they opt out.

Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.

For my infrastructure, updates, of what ever kind, need to be incorporated into 
the test/build/roll-out cycle.

Unless I misunderstand the intent of this thread.

So, as an accommodation,  a flag in the preseed mechanism to enable/disable 
would be helpful.  But would need to be exposed in maybe the expert mode menus, 
which I think was already mentioned.


> 
> And yes, this would be a change in behaviour we should prominently
> document, but nonetheless do.
> 
> 
> --
> cheers,
>   Holger, who has systems where he wants those and others where
>   not.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Holger Levsen]

On Sun, Dec 10, 2017 at 04:13:12PM +, Holger Levsen wrote:
> I think its totally adequate to assume people want automatic security updates,
> on all kinds of systems, unless they opt out.

also because people like consistancy.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Holger Levsen]

On Sun, Dec 10, 2017 at 12:34:08PM +0100, Moritz Mühlenhoff wrote:
> This is not an adequate default for non-Desktop setups, this should rather be
> pulled in via some of the desktop tasksel tasks, but not in general.

I think its totally adequate to assume people want automatic security updates,
on all kinds of systems, unless they opt out.

And yes, this would be a change in behaviour we should prominently
document, but nonetheless do.


-- 
cheers,
Holger, who has systems where he wants those and others where
not.


signature.asc
Description: PGP signature

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Moritz Mühlenhoff]

On Fri, Sep 15, 2017 at 03:27:58PM +0100, Steve McIntyre wrote:
> On Fri, Sep 15, 2017 at 11:45:13AM +0200, Raphaël Hertzog wrote:
> >Source: pkgsel
> >Version: 0.45
> >Severity: wishlist
> >
> >Ubuntu has a patch adding a "pkgsel/update-policy" debconf question which
> >is used to control the installation of unattended-upgrades. I want to
> >merge this into Debian.
> >
> >The biggest question in this work is the default value and priority of
> >the question.
> >
> >Ubuntu defaults to "none" (no automatic installation) but asks the
> >question at high priority on netboot (non-cdrom) images or on their
> >server images.
> >
> >For Debian, I don't think that making such a difference makes sense.
> >We should:
> >- either always show the question with its default value of "none"
> >  (thus making sure that they have a chance to opt-in to this feature)
> >- or not show the question (priority "medium") but make it default
> >  to install unattended-upgrades so that they get updates by default but
> >  have a chance to disable that with preseeding
> >
> >Given the last discussion on -devel
> >(https://lists.debian.org/debian-devel/2016/11/threads.html#00117) I think
> >we should make a bold choice and do the latter.
> >
> >I'm going to submit a tested patch later on.
> 
> Sounds reasonable, yes.

I don't think so.

This is not an adequate default for non-Desktop setups, this should rather be
pulled in via some of the desktop tasksel tasks, but not in general.

Cheers,
Moritz

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Control: tag -1 + patch

On Fri, 15 Sep 2017, Steve McIntyre wrote:
> >For Debian, I don't think that making such a difference makes sense.
> >We should:
> >- either always show the question with its default value of "none"
> >  (thus making sure that they have a chance to opt-in to this feature)
> >- or not show the question (priority "medium") but make it default
> >  to install unattended-upgrades so that they get updates by default but
> >  have a chance to disable that with preseeding
> >
> >Given the last discussion on -devel
> >(https://lists.debian.org/debian-devel/2016/11/threads.html#00117) I think
> >we should make a bold choice and do the latter.
> >
> >I'm going to submit a tested patch later on.
> 
> Sounds reasonable, yes.

Ok, so here's my set of patches. Relevant to this bug are the first and
the last one. The other commits are other random improvements that I merged
from Ubuntu that looked like useful.

I tested the attached patches on modified mini.iso where I force-injected
pkgsel and bootstrap-base (because I could not manage to get anna to
reload the modified templates if I installed the new pkgsel manually once
the installer was started up to the configure network step).

Reviews are welcome.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
>From 07855172bf545b6c6e632b4f3c6e267b056d5862 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Fri, 15 Sep 2017 11:29:00 +0200
Subject: [PATCH 1/7] Merge pkgsel/update-policy preseed from Ubuntu to offer
 to install unattended-upgrades.

---
 debian/changelog |  7 +++
 debian/pkgsel.templates  | 13 +
 pre-pkgsel.d/20update-policy | 41 +
 3 files changed, 61 insertions(+)
 create mode 100755 pre-pkgsel.d/20update-policy

diff --git a/debian/changelog b/debian/changelog
index d9934a7..5dd6dc7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pkgsel (0.46) UNRELEASED; urgency=medium
+
+  * Merge pkgsel/update-policy preseed from Ubuntu to offer to install
+unattended-upgrades.
+
+ -- Raphaël Hertzog   Fri, 15 Sep 2017 11:26:14 +0200
+
 pkgsel (0.45) unstable; urgency=medium
 
   * Export DEBIAN_TASKS_ONLY=1 when running tasksel in target, to make
diff --git a/debian/pkgsel.templates b/debian/pkgsel.templates
index 6ce4290..0b8fd54 100644
--- a/debian/pkgsel.templates
+++ b/debian/pkgsel.templates
@@ -48,3 +48,16 @@ Description: for internal use; can be preseeded
 Template: pkgsel/progress/fallback
 Type: text
 _Description: Running ${SCRIPT}...
+
+Template: pkgsel/update-policy
+Type: select
+Default: none
+Choices-C: none, unattended-upgrades
+__Choices: No automatic updates, Install security updates automatically
+_Description: How do you want to manage upgrades on this system?
+ Applying updates on a frequent basis is an important part of keeping your
+ system secure.
+ .
+ By default, updates need to be applied manually using package management
+ tools. Alternatively, you can choose to have this system automatically
+ download and install security updates.
diff --git a/pre-pkgsel.d/20update-policy b/pre-pkgsel.d/20update-policy
new file mode 100755
index 000..c3588da
--- /dev/null
+++ b/pre-pkgsel.d/20update-policy
@@ -0,0 +1,41 @@
+#!/bin/sh
+
+set -e
+. /usr/share/debconf/confmodule
+
+DISTRIB_ID=$(. /target/etc/os-release; echo $ID)
+DISTRIB_ID_LIKE=$(. /target/etc/os-release; echo $ID_LIKE)
+
+if [ "$DISTRIB_ID" = "ubuntu" ] || [ "$DISTRIB_ID_LIKE" = "ubuntu" ]; then
+	# Ubuntu hack to ask this at high priority on server or netboot
+	# installations, medium otherwise
+	if [ ! -d /cdrom/.disk ] || grep -iq server /cdrom/.disk/info; then
+		update_priority=high
+	else
+		update_priority=medium
+	fi
+else
+	# In Debian, we always ask the question
+	update_priority=high
+fi
+
+db_input "$update_priority" pkgsel/update-policy || true
+db_go || true
+db_get pkgsel/update-policy
+if [ "$RET" = none ]; then
+	# We might pull in unattended-upgrades, which defaults to doing security
+	# updates automatically. Seed it to have auto updates disabled so that if
+	# we *do* pull it in, it won't break stuff.
+	echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean false' | \
+		log-output -t pkgsel chroot /target debconf-set-selections || \
+		true
+elif [ "$RET" = unattended-upgrades ]; then
+	# unattended-upgrades defaults to true on installation if otherwise untouched.
+	apt-install unattended-upgrades || true
+elif [ "$RET" = landscape ]; then
+	# This is Ubuntu-specific but does no harm here
+	echo 'landscape-client landscape-client/register_system boolean true' | \
+		log-output -t pkgsel chroot /target debconf-set-selections || \
+		true
+	apt-install landscape-client || true
+fi
-- 
2.14.1

>From 391eb9457ec44eaa8d2a4603fcbf6c9c2a581821 Mon 

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Steve McIntyre]

On Fri, Sep 15, 2017 at 11:45:13AM +0200, Raphaël Hertzog wrote:
>Source: pkgsel
>Version: 0.45
>Severity: wishlist
>
>Ubuntu has a patch adding a "pkgsel/update-policy" debconf question which
>is used to control the installation of unattended-upgrades. I want to
>merge this into Debian.
>
>The biggest question in this work is the default value and priority of
>the question.
>
>Ubuntu defaults to "none" (no automatic installation) but asks the
>question at high priority on netboot (non-cdrom) images or on their
>server images.
>
>For Debian, I don't think that making such a difference makes sense.
>We should:
>- either always show the question with its default value of "none"
>  (thus making sure that they have a chance to opt-in to this feature)
>- or not show the question (priority "medium") but make it default
>  to install unattended-upgrades so that they get updates by default but
>  have a chance to disable that with preseeding
>
>Given the last discussion on -devel
>(https://lists.debian.org/debian-devel/2016/11/threads.html#00117) I think
>we should make a bold choice and do the latter.
>
>I'm going to submit a tested patch later on.

Sounds reasonable, yes.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphaël Hertzog]

Source: pkgsel
Version: 0.45
Severity: wishlist

Ubuntu has a patch adding a "pkgsel/update-policy" debconf question which
is used to control the installation of unattended-upgrades. I want to
merge this into Debian.

The biggest question in this work is the default value and priority of
the question.

Ubuntu defaults to "none" (no automatic installation) but asks the
question at high priority on netboot (non-cdrom) images or on their
server images.

For Debian, I don't think that making such a difference makes sense.
We should:
- either always show the question with its default value of "none"
  (thus making sure that they have a chance to opt-in to this feature)
- or not show the question (priority "medium") but make it default
  to install unattended-upgrades so that they get updates by default but
  have a chance to disable that with preseeding

Given the last discussion on -devel
(https://lists.debian.org/debian-devel/2016/11/threads.html#00117) I think
we should make a bold choice and do the latter.

I'm going to submit a tested patch later on.

-- System Information:
Debian Release: buster/sid
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)