Missing daily builds: manual builds started

[Cyril Brulebois]

Hi,

JFYI alioth seems to have been unreachable past night when daily builds
were attempted, which means they're all lacking right now. I've started
a build on most porterboxes a few minutes ago, so new builds should
appear before the next scheduled run (around 00Z for most archs).


KiBi.


signature.asc
Description: Digital signature

Tentative summary (Re: Should apt-transport-https be Priority: Important ? (Re: own cloud task in tasksel?))

[Charles Plessy]

Le Tue, Mar 15, 2016 at 11:07:44AM -0400, Brian Gupta a écrit :
> On Mon, Mar 14, 2016 at 9:26 PM, Charles Plessy  wrote:
> >
> > With the worldwide effort of using HTTPS everywhere, I wonder if
> > apt-transport-https shouldn't be installed by default anyway on systems with
> > network connectivity, that is, its priority should be Important.  What do
> > people think about this ?  Would it make sense to raise the question on
> > debian-devel ?
> 
> If you think this makes sense, I'd raise it on debian-devel, and move
> the debate there.
> 
> Going to all https is a worthy goal, especially now that Let's
> Encrypt has been launched.

Hi Brian and everybody,

while the discussion that happened did not lead to a consensus, I think that it
is time to summarise.  And while the outcome is still uncertain, I think that
it is worthwile to move the debate to debian-devel, where more insights may be
gathered.

In brief:

For a Debian system to use encrypted transport when downloading packages from
an APT mirror that has been appropriately set up, the packages
apt-transport-https and its dependancies must be installed.  Would it be a good
service for our users to install this by default by setting this package's
priority to "Important" ?

The question can be rephrased as "are the gains high enough compared to the 
costs ?"

Here are the gains:

 - Using HTTPS partially hides information about what a user installs on his 
machine.

 - Having HTTPS support by default means that users can switch directly to HTTPS
   anytime they wish: the system is ready, there is nothing to learn (which 
package
   to install) or to do (get the packages with either APT over HTTP or with
   other tools and then install them with dpkg).  Note that the use of plain 
HTTP
   may be mandatory in some environments.

 - We send a message to our users and the world, that we give a high importance 
to
   the defense of people's privacy.

Here are limitations to these gains.

 - APT over HTTPS does not fully protect from surveillance, because by
   analysing metadata such as the size of the transfers, one may deduce which
   packages are being downloaded.  Thus, it has been proposed that APT
   over HTTPS is not good enough and that APT over TOR should be proposed 
instead.

 - Most mirrors are not providing HTTPS yet, thus it is prematurate to enable
   HTTPS support by default.  (By the way, will the content delivery network
   debs.debian.org provide HTTPS support ?)

 - Opinions may widely differ on the impact and appropriateness of driving 
technical
   choices (installing packages that most people will not use in the short term)
   with political views (defense of privacy).  [This may be rephrased, but this
   is to reflect Marco's derogatory words ("privacy fetish") in the discussion]

And here are the costs.

 - On a system freshly created with debootstrap, installing apt-transport-https
   eats roughly 10 Mo of space.

 - The following other packages are installed: ca-certificates krb5-locales 
libcurl3-gnutls
   libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 
libldap-2.4-2 libnghttp2-14
   librtmp1 libsasl2-2 libsasl2-modules libsasl2-modules-db libssh2-1 openssl.
   This increases the system's complexity.

Limitations to these costs:

 - Systems where disk space is crucial are or can be constructed by starting 
from the
   smaller subset of "Required" packages (supported in debootstrap by the 
"minbase" option).

 - Systems where disk space costs (like cloud images) are not necessarly billed 
at a
   granularity where 10 Mo matters.  For instance on the Amazon cloud, users 
are billed
   per Gigabyte, therefore installing apt-transport-https by default would
   only cost in case it would cause images sizes to increase to the next 
gigabyte.

Comments are very welcome.  If I have forgotten something, if you think I 
misrepresented
some points of view, or simply if you would like to continue the discussion 
before
transfering it to debian-devel, please go ahead !

Have a nice day,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#819300: should provide default HTTPS mirrors for non-Debian releases too

[Evgeni Golov]

Package: debootstrap
Version: 1.0.80
Severity: wishlist

Hi,

currently debootstrap only knows about an HTTPS mirror for Debian, but not e.g. 
for Ubuntu.
This can have funny results when trying to bootstrap an Ubuntu release w/o 
having ubuntu-archive-keyring installed:

% sudo debootstrap xenial /tmp/xenial
I: Keyring file not available at 
/usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https mirror 
https://mirrors.kernel.org/debian
I: Retrieving Release 
E: Failed getting release file 
https://mirrors.kernel.org/debian/dists/xenial/Release

Explicitly setting the mirror helps. But I think the Ubuntu scripts should not 
only override DEF_MIRROR but also DEF_HTTPS_MIRROR.

Greets
Evgeni

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

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

Versions of packages debootstrap depends on:
ii  wget  1.17.1-1+b1

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.20-4

debootstrap suggests no packages.

-- no debconf information

Bug#819288: console-setup-linux: keyboard-setup.sh init script (actually, the cached scripts) rely on /tmp, which may not be mounted at early boot

[Anton Zinoviev]

On Sat, Mar 26, 2016 at 12:53:45AM -0300, Felipe Sateler wrote:
> 
> The cached scripts rely on the compiled keyboard maps to be present in
> /tmp (presumably by having being saved by setupcon -k).

Hm, this is totaly unexpected.  Normally the cached scripts rely on 
compiled keyboard maps in /etc.

The only reason I can see the cached scripts rely on maps in /tmp is 
that /etc/ was read-only when `setupcon --save-only` was executed by 
/etc/init.d/console-setup.sh or `dpkg-reconfigure`.

The cached scripts should never rely on files in /tmp and this is a bug 
I will have to fix somehow.  However, an important question we have to 
investigate here is this: why in your system the cached scripts rely on 
files in /tmp.

Anton Zinoviev