Re: Linking coreutils against OpenSSL

[Florian Weimer]

* Theodore Ts'o:

> If you can get upstream a patch so that coreutils could try to dlopen
> OpenSSL and use it if it is available, but skip it if it is not, that
> might be one way to avoid OpenSSL going into essential.  The challenge
> is that OpenSSL is not known for its ability to maintain a stable ABI,
> but if we only care about supporting a specific version of OpenSSL
> (the one which is shipped with coreutils) and given that the fallback
> is a slower sha256sum, which IMHO is *not* a disaster, perhaps it's
> doable?

I think the OpenSSL 3 ABI should be stable for quite some time.  It's
probably not even necessary to use dlvsym instead of dlsym because I
think OpenSSL upstream just adds new functions if they need new
behaviors.

Re: RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)

[Florian Weimer]

* G. Branden Robinson:

> Perhaps the thing to do here is have, , yet another command-line
> option for GCC.  The Ada language did something similar a couple of
> decades ago to tighten up the language for hard real-time demands, with
> what it called the "Ravenscar profile".[1]  That proved successful (as
> successful as anything was in poor neglected Ada).

The C++ front end calls this -fpermissive, which would probably match
here as well.

> Whatever its name, some advantages to this approach are that
> distributors could opt-in to such a thing, make it a clear matter of
> policy, and more easily track adoption and progress.  You could also
> version the contour much like the C standard itself.

I'm not sure if we need this fine level of control.  Either you want to
compile at all costs, or you are willing to make the effort to clean up
the sources.  At a package level, the required changes are almost always
minor (but of course there are packages that are different), so fixing
everything in one go (and the implied commitment to keep up with future
cleanups_ is not very onerous.  For one package, that is.

I'm not sure if opt-in is that easy because packages drop build flags
all the time.  Compiler wrapper scripts might be required.  The
instrumented compiler we use in Fedora sometimes reveals things that go
unnoticed with other approaches.

Thanks,
Florian

RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)

[Florian Weimer]

TL;DR: I want to propose a GCC 14 change which will impact
distributions, so I'd like to gather some feedback from Debian.

Clang has disabled support for a few historic C features by default over
the last few releases.  This mirrors a process that Apple has begun in
Xcode even earlier (perhaps motivated in part by their AArch64 Darwin
ABI, which is pretty much incompatible with some of the C89-only
features).

These changes bring real benefits to C programmers because errors are
much harder to miss during the build than warnings.  In many cases, the
compiler is not able to generate correct code when such issues are
present, and programmers who look at the generated machine code suspect
a compiler bug.  And all this happens because they missed a warning.  So
we want this change for GCC, too.

On the other hand, many distributions use GCC as the system compiler,
and there the focus is not so much on developing software, but building
the sources as they exist today.  It's somewhat different the usual GCC
C++ updates (both language changes and libstdc++ header changes) because
it impacts pre-build feature probing (mostly autoconf).  If that happens
and the probe goes wrong due to a new compiler error, it's possible that
a build still succeeds, passes its test suite, but lacks the intended
feature or ABI because parts got automatically disabled due to the
failing configure check.  With C++ transitions, that seems more rare
(C++ programs—if they use autoconf—often run the checks with the C
compiler).

Specifically, I'm investigating the following changes:

* -Werror=implicit-function-declaration: Functions can no longer be
   called without be declaring first.  Fixing this may need additional
   prototypes in package header files, or inclusion of additional header
   files (both package-specific and system headers).

* -Werror=implict-int: int types can no longer be omitted in old-style
   function definitions, function return types, or variable declarations
   or definitions.  Fixing that involves adding the int type (or the
   correct type if it is not actually int).  If there is already a
   matching declaration in scope that has a different type, that needs
   to be resolved somehow, too.

* (tentative) -Werror=int-conversion: Conversion between pointer and
  integer types without an explicit cast is now a compiler error.
  Usually fixed by one of the two things above.  I do not have data yet
  how many other cases remain after the initial issues are fixed, but
  should have that in the coming weeks.  (Quite frankly, I'm amazed that
  we created 64-bit ports without making this an error.)

* (very tentative) -Werror=incompatible-pointer-types: GCC will no
  longer automatically convert between pointer values of unrelated
  pointer types (except when one of them is void * or its qualified
  versions).  The fallout from this could be quite large, I do not have
  data yet.  Clang does this for function pointer types only (probably
  based on their ABI issues), but I'm not sure if it's a reasonable
  distinction for our ABIs (the ppc64le cases I've seen had explicit
  casts and no warnings).

* For -Wdiscarded-qualifies (e.g., using const pointers as non-const),
  and -Wpointe-rsign (using char * as unsigned char *) I do not have any
  plans.

I want to propose at least the first two for GCC 14.

The exact mechanism how the default is changed may not be -Werror=,
perhaps something along the lines of -fpermissive for C++.  The C89
modes (-std=gnu89 etc.) will likely still enable all these features
(even if they are not part of C89).  As an opt-out mechanism, -std=gnu89
is insufficient because there are packages out there which use features
which are C99-and-later-only in GCC (predominantly C99-style inlining, I
believe) together with implicit-int/implicit-function-declaration.

For Fedora, we are using an instrumented compiler to find packages that
need fixing.  More details on the process are here (but please ask if
you are interested in specifics):

  
  

The numbers so far don't look great, but are manageable.  Fedora has
23,101 source package last time a looked.  We have fixed 796 of them,
and 85 are still pending investigation (with 5-10 false positives
expected remaining).  This puts the per-package failure rate at 3.8%.  I
don't have data on silent failures; most issues do not seem to be
silent, and fully-silent packages are rare.  The silent output-changing
issues definitely exist, they are usually accompanied by something else.
Those 3.8% also include some packages which we fixed by removing C89
constructs, but where the relevant autoconf tests failed for other
reasons.

Fedora would be hit pretty hard if we made the GCC switch without this
preparation because we do a mass rebuild of the entire distribution
right after importing a new GCC upstream release.  I have considered
automating 

Re: Intel CET Support?

[Florian Weimer]

* Felix Potthast:

> i just stumbled upon the fact that debian doesn't yet make use of the
> Intel CET security feature, while many other distributions
> (Ubuntu, Fedora, Suse, Arch Linux) do.

There's no kernel support for userspace CET, and it's been missing for
many years now.  The userspace ABi will change, but the hope is that a
glibc update is sufficient to enable it for those distributions that
are already built to spec.  Reportedly, Fedora mostly works with
custom kernels (not the Fedora kernel though; it follows mainline).
There's some hope that userspace CET lands in an upcoming 6.y kernel
upstream, with a low value for y, but we've been disappointed
countless times.

The most interesting part is probably the shadow stack and the
efficient backtrace generation it enables (the full call stack, not
just the last 32 or so frames, as with LBR; and even faster than
frame-pointer traversal).  This particular part of CET is already
available in AMD's Zen 3 CPUs, not just Intel's Tigerlake and later
CPUs.

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Florian Weimer]

* Aurelien Jarno:

> Hi,
>
> On 2021-12-02 19:51, Florian Weimer wrote:
>> I'd like to provide an ld.so command as part of glibc.  Today, ld.so can
>> be used to activate preloading, for example.  Compared to LD_PRELOAD,
>> the difference is that it's specific to one process, and won't be
>> inherited by subprocesses—something is that exactly what is needed.
>> There is also some useful diagnostic output in --help,
>> --list-diagnostics.
>
> This sounds a good idea, I guess for instance that in the future the ldd
> feature could be implemented as an option.
>
> However before exposing directly to user, there might be some work need
> to improve error reporting. For instance running the dynamic linker
> against a static library like ldconfig just causes a segmentation fault
> (at least in 2.34, I haven't tried in HEAD). I haven't tried either
> binaries from other libc, but we should make sure that an error is
> correctly reported if users try that. At least a binary from a different
> architecture correctly reports the error.

I filed <https://sourceware.org/bugzilla/show_bug.cgi?id=28648> for that.

I have a patch that uses execve in those cases.  So ”ld.so
/sbin/ldconfig” will work in the future.  This has some backwards
compatibility impact: In theory there might be objects which do not have
dynamic dependencies, but use a program interpreter, using custom
startup code.  Running those objects would lose dynamic loader
customization.

“ld.so /path/to/lib.so” crashes for completely different reasons: due to
a recently fixed binutils bug, shared objects have a fictitious entry
point set by BFD ld.  Due to the bug, the address is in an loadable,
executable segment (it's the start of the .text section), so we can't
detect this situation in the dynamic loader.  This will only go away
once shared objects are linked with a fixed ld.

>> Having ld.so as a real command makes the name architecture-agnostic.
>> This discourages from hard-coding non-portable paths such as
>> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
>> /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 in scripts that require
>> specific functionality offered by such an explicit loader invocation.
>
> Do you actually have example of usage of the non-ABI-compliant dynamic
> loader in Debian? Independently of the current discussion, this should
> probably be fixed.

There are few suspicious examples in source code:

  <http://codesearch.debian.net/search?q=%2Flib%2F.*-gnu%2Fld-linux=0>

I have not scanned ELF binaries in built packages.

>> I thought that commands with file extensions might be Policy violation.
>> Policy actually talks about file extensions for programs installed in
>> /usr/bin—but only for scripts.  So it's technically okay.  And today,
>> there's already an ld.so manual page, although it's in section 8 and 1.
>> (I think /usr/bin is still appropriate because running ld.so does not
>> require special privileges.)
>> 
>> The initial implementation will be just a symbolic link.  This means
>> that multi-arch support will be missing: the amd64 loader will not be
>> able to redirect execution to the s390x loader.  In principle, it should
>> be possible to find PT_INTERP with a generic ELF parser and redirect to
>> that, but that's vaporware at present.  I don't know yet if it will be
>> possible to implement this without some knowledge of Debian's multi-arch
>> support in the loader.  Upstream doesn't have those features (we only
>> support /usr/lib vs /usr/lib64 and some minor variants of that), so
>> integration might be lacking.
>
> A simple symlink would work as a start, however it means creating a
> new non-multiarch package. If we want that feature to be available to
> all system, we need a way to ensure this package is automatically
> installed.
>
> What is the plan about supporting /usr/lib vs /usr/lib64? If upstream go
> the wrapper way, there might not be a lot of differences with what is
> needed to support multiarch. From what I understand a wrapper would need
> to have a basic understanding of the arguments passed to ld.so to find
> the binary that needs to be loaded. Looking at PT_INTERP is one way to
> go, however we should define what would be the behaviour for non GNU
> libc dynamic loader.

There is not going to be a wrapper.  We will integrate the logic into
ld.so itself, teaching it to execve a different loader.  All ld.so's
will have this capability, so it won't matter which one ends up as
/usr/bin/ld.so, except for performance reasons.

Basically, if we detect an incompatible architecture, we will fetch
PT_INTERP from the executable and execve that, using mostly the original
dynamic linker command line.  At least that's my plan.

>>

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Florian Weimer]

* Helmut Grohne:

> Hi Florian,
>
> On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote:
>> We can add a generic ELF parser to that ld.so and use PT_INTERP, as I
>> mentioned below.  I think this is the way to go.  Some care will be
>> needed to avoid endless loops, but that should be it.
>
> Can I ask you to go into a bit more technical detail as to how this is
> supposed to work?

Sure!

> From what was said, I expect that /usr/bin/ld.so is an ELF executable.
> It will likely be part of libc-bin. Do you confirm?

Yes, that's what I expect as well.

> Since libc-bin is Multi-Arch: foreign. The new ld.so really must have an
> architecture-independent API. If it does not, it must not go there.

It is as architecture-independent as ldconfig or getconf.  Perhaps a bit
more so than getconf.

> As far as I understand things, the typical use will be "ld.so
> --preload somelib someprogram". Now consider an i386 ld.so, an amd64
> somelib and an amd64 someprogram. Will that work with the generic ELF
> parser?
>
> At present, it does not seem to work:
>
> $ /lib/ld-linux.so.2 --preload /usr/lib/x86_64-linux-gnu/libeatmydata.so 
> /bin/true
> /bin/true: error while loading shared libraries: /bin/true: wrong ELF class: 
> ELFCLASS64
> $

As has explained elsewhere, you need to use $LIB or just the soname (so
that ld.so searches the right paths).  I expect this to work eventually:

  ld.so --preload libeatmydata.so /bin/true

Even if /bin/true is an i386 program, assuming that libeatmydata1:i386
is installed.  Whether ld.so is built for i386 or amd64 will not matter.

> If that is what you will get from /usr/bin/ld.so, then it must not be
> part of libc-bin or Multi-Arch: foreign must be dropped. The latter
> likely is a non-option due to the amount of resulting breakage.

With the patch I've posted, you'll get the ELFCLASS64 error.  But I have
some ideas how to fix that eventually.  Is this sufficient for now?

Thanks,
Florian

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Florian Weimer]

* Simon McVittie:

> On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
>> Having ld.so as a real command makes the name architecture-agnostic.
>> This discourages from hard-coding non-portable paths such as
>> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
>> /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 in scripts that require
>> specific functionality offered by such an explicit loader invocation.
>
> This works up to a point, but because there is only one /usr/bin/ld.so,
> it can only work for one architecture per machine, so saying it's
> architecture-agnostic is still a bit of a stretch.

We can add a generic ELF parser to that ld.so and use PT_INTERP, as I
mentioned below.  I think this is the way to go.  Some care will be
needed to avoid endless loops, but that should be it.

Things will break if people link with --dynamic-linker=/usr/bin/ld.so,
but that's just broken (like using --dynamic-linker=/lib/dl-2.33.so
today).

>> In principle, it should
>> be possible to find PT_INTERP with a generic ELF parser and redirect to
>> that, but that's vaporware at present.  I don't know yet if it will be
>> possible to implement this without some knowledge of Debian's multi-arch
>> support in the loader.
>
> I believe Debian uses the interoperable (ABI-compliant) ELF interpreter
> as listed on https://sourceware.org/glibc/wiki/ABIList for all
> architectures - it certainly does for all *common* architectures (for
> example our x86_64 executables use /lib64/ld-linux-x86-64.so.2, which is
> a special exception to the rule that we don't usually use lib64).

I'm not aware of any Debian divergence yet, either.

If we can just run any specified PT_INTERP and use something else for
loop detection (e.g., an additional argument), then it should probably
work out of the box.  I was just trying to set expectations because I
had not really thought about it in detail, in particular the loop
avoidance scheme and it whether it must know about all the known
loaders.

Some distributions also want to avoid code execution from ldd.  Another
thing to consider before lifting paths out of PT_INTERP.

> I had naively believed that all distros do the same, but unfortunately
> my work on the Steam Runtime has taught me otherwise: for example, Arch
> Linux has a non-standard ELF interpreter /usr/lib/ld-linux-x86-64.so for
> executables that are built from the glibc source package (but uses the
> interoperable ELF interpreter for everything else),

/usr/lib/ld-linux-x86-64.so could be a botched attempt at completing
UsrMove.  The upstream makefiles are not really set up for that.

> and Exherbo consistently puts their dynamic linkers in
> /usr/x86_64-pc-linux-gnu/lib.

No idea about that one.

> Does glibc automatically set up the interoperable ELF interpreter, or is
> it something that distros' glibc maintainers have to "just know" if they
> are using a non-default ${libdir}?

With ./configure --prefix=/usr, upstream glibc is expected to use the
official path in the file system (and it should no longer be a symbolic
link, either).  The just-built binaries should use that path, too.

But the dynamic linker pathname is not entirely unique, which creates
problems for Debian-style multi-arch.

>> If someone wants to upstream the multi-arch patches, that would be
>> great.  glibc now accepts submissions under DCO, so copyright assignment
>> should no longer be an obstacle.
>
> (Please note that I am not a glibc maintainer and cannot speak for them.)
>
> I think multiarch is mostly build-time configuration rather than patches.
> The main thing needing patching is that we want ${LIB} to expand to
> lib/x86_64-linux-gnu instead of just x86_64-linux-gnu, so that the
> "/usr/${LIB}/libfoo.so.0" idiom works, but glibc would normally only take
> the last component of the ${libdir}:
>
> https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/any/local-ld-multiarch.diff

That must get the data from somewhere else.  Looking at

  <https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/rules.d/build.mk>

it seems to come from DEB_HOST_MULTIARCH, and that's:

| DEB_HOST_MULTIARCH?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

We would have to take the table out of dpkg-architecture and put it into
upstream glibc (or gcc or binutils), otherwise you can't build a
multi-arch glibc on a non-Debian system.  Something like a generic
--with-multiarch-tuple= configure option would sidestep that, but risk
that different distributions end up with different multi-arch tuples.

> The freedesktop.org SDK used for Flatpak also uses Debian-style multiarch
> (but is not otherwise Debian-derived), and addresses that differently, in a
> way that might be more upstream-suitable:
>
> https://gitlab.com/freedesk

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Florian Weimer]

* Theodore Y. Ts'o:

> * How does ld.so --preload *work*?

The dynamic loader has an array of preloaded sonames, and it processes
them before loading the dependencies of the main program.  This way,
definitions in the preloaded objects preempt definitions in the shared
objects.

> * Does it modify /bin/ls, so that all users running /bin/ls get the
> preloaded library?

No, it's purely a run-time change.

The global setting is in /etc/ld.so.preload.

> * Does it modify something in the user's home directory?

No.  Well, the shell might put that command into .bash_history, or
something like that.

> * How do you undo the effects ld.so --preload?

You run the program without the --preload option.  Or unset LD_PRELOAD.

Thanks,
Florian

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Florian Weimer]

* Bastian Blank:

> On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
>> Right, thanks for providing a concrete example.  A (somewhat) portable
>> version would look like this:
>>   ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl
>
> You mean
>   ld.so --preload libeatmydata.so.1.3.0 /bin/ls
> ?

Right, that is even better.

No objects to /usr/bin/ld.so then?

Thanks,
Florian

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Florian Weimer]

* Paul Wise:

> Florian Weimer wrote:
>
>> I'd like to provide an ld.so command as part of glibc.
>
> Will this happen in glibc upstream or just in Debian?

Upstream, and then Debian.  The symbolic link would likely and up in
libc-bin in Debian.

>> Today, ld.so can be used to activate preloading, for example. 
>> Compared to LD_PRELOAD, the difference is that it's specific to one
>> process, and won't be inherited by subprocesses—something is that
>> exactly what is needed.
>
> That appears to be activated like this:
>
> /lib64/ld-linux-x86-64.so.2 --preload 
> /usr/lib/x86_64-linux-gnu/libeatmydata.so.1.3.0 /bin/ls

Right, thanks for providing a concrete example.  A (somewhat) portable
version would look like this:

  ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl

This assumes that $LIB expands to the multi-arch subdirectory.
(In upstream, it switches between lib, lib64, libx32 as needed.)

>> Anyway, do you see any problems with providing /usr/bin/ld.so for use
>> by skilled end users?
>
> It means more folks get exposed to ld.so features, which might mean
> more support and feature requests for glibc upstream,. For example the
> set of features provided by environment variables is different to the
> set of features provided by command-line options.

The intent of this change is to expose these loader features to more
users and tools.  This came up for --list-diagnostics, where we'd
otherwise had to teach the sos tool (and others) how to find the loader
path.

Thanks,
Florian

/usr/bin/ld.so as a symbolic link for the dynamic loader

[Florian Weimer]

I'd like to provide an ld.so command as part of glibc.  Today, ld.so can
be used to activate preloading, for example.  Compared to LD_PRELOAD,
the difference is that it's specific to one process, and won't be
inherited by subprocesses—something is that exactly what is needed.
There is also some useful diagnostic output in --help,
--list-diagnostics.

Having ld.so as a real command makes the name architecture-agnostic.
This discourages from hard-coding non-portable paths such as
/lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 in scripts that require
specific functionality offered by such an explicit loader invocation.

I thought that commands with file extensions might be Policy violation.
Policy actually talks about file extensions for programs installed in
/usr/bin—but only for scripts.  So it's technically okay.  And today,
there's already an ld.so manual page, although it's in section 8 and 1.
(I think /usr/bin is still appropriate because running ld.so does not
require special privileges.)

The initial implementation will be just a symbolic link.  This means
that multi-arch support will be missing: the amd64 loader will not be
able to redirect execution to the s390x loader.  In principle, it should
be possible to find PT_INTERP with a generic ELF parser and redirect to
that, but that's vaporware at present.  I don't know yet if it will be
possible to implement this without some knowledge of Debian's multi-arch
support in the loader.  Upstream doesn't have those features (we only
support /usr/lib vs /usr/lib64 and some minor variants of that), so
integration might be lacking.

If someone wants to upstream the multi-arch patches, that would be
great.  glibc now accepts submissions under DCO, so copyright assignment
should no longer be an obstacle.

Anyway, do you see any problems with providing /usr/bin/ld.so for use by
skilled end users?

Thanks,
Florian

Figuring how to work with team-maintained packages on salsa

[Florian Weimer]

I want to add a few patches to this repository:

  

Surely there must be some tool support to help with that?  I know how
to do it manually (perhaps even involving quilt).  Has every Debian
developer their own script for that?  (It's like this in RPM land …)

Re: How to commit a new architecture like RISC-V

[Florian Weimer]

* zhangjialing:

> 在 2021/5/11 下午6:36, Helmut Grohne 写道:
>>   * What is the state of glibc support

> 2.28-10,patch can provide

There's been any port submission posted to libc-alpha.

By default, new ports use the current glibc ABI baseline (which would
now be glibc 2.34, which is still evolving during development).  It is
theoretically possible to back-date ABIs (so that a new port
contributed for, say, glibc 2.35 would use the 2.28 ABI baseline for
that architecture, as if it had been contributed during 2.28
development), but that needs some discussion with the glibc
developers.  If Debian adopts the 2.28 ABI but upstream does not,
Debian will experience an ABI break once the port is merged upstream.

Re: CentOS and Debian/Ubuntu release cycles

[Florian Weimer]

* Stephan Lachnit:

> The more I started thinking about it, the more I wondered about why
> Debian Stable and Ubuntu LTS are *not* binary-compatible.

They have different branching points from Debian unstable/upstream, so
they end up with different versions of the toolchain and core
libraries.  Many of the core libraries offer backwards compatibility,
but no forward compatibility (unless their interface happens not to
change), so you have to build on system with the oldest libraries to
be compatible with multiple different distributions.

I'm not sure to what extent this is relevant to CentOS as released.
CentOS (Stream or not does not matter) is not a typical LTS
distribution: the change rate due to backporting and rebases is quite
high.  For something that matches Debian stable, you need to look at
Extended Update Support (EUS) for Red Hat Enterprise Linux, but that
has never been available through CentOS.  Conversely, I don't think
there's an equivalent to mainline (non-EUS) Red Hat Enterprise Linux
(or CentOS) in the Debian world.  Debian's backports repository may
offer an approximation in some areas, but its scope is quite limited.

On the other hand, many CentOS users actually seem to want something
that is much closer to EUS than what they get from CentOS today, and
for them, Debian stable is probably a good fit.

Re: Proposal: Allowing access to dmesg for users in group adm

[Florian Weimer]

* Nicholas D. Steeves:

> Given that our default sudoers (and afaik Ubuntu's) provides the
> following rule
>
>   %sudo   ALL=(ALL:ALL) ALL
>
> would it be reasonable to modify this proposal to use the "sudo" rather
> than "adm" group, given that we don't yet have a default mechanism to
> enforce a "if groups = (sudo AND adm)" mechanism?

I don't think so.  sudo should be dedicated to sudo access management.
I expect that system administrators would be surprised if it confers
completely unrelated privileges.

Re: Bug#958710: ITP: nss-tls -- encrypted glibc name resolving library which uses DNS-over-HTTPS (DoH)

[Florian Weimer]

* Scott Kitterman:

> On Friday, April 24, 2020 11:54:17 AM EDT Kan-Ru Chen wrote:
>> Hi,
>> 
>> On Sat, Apr 25, 2020, at 12:34 AM, Scott Kitterman wrote:
>> > On Friday, April 24, 2020 11:11:49 AM EDT Kan-Ru Chen wrote:
>> > > * Package name: nss-tls Description : encrypted glibc name
>> > > 
>> > >   resolving library which uses DNS-over-HTTPS (DoH)
>> > > 
>> > > nss-tls is an alternative, encrypted name resolving library to use
>> > > with glibc, which uses DNS-over-HTTPS (DoH).
>> > 
>> > Without knowing more that what is in the ITP, nss-tls seems like a
>> > counter-
>> > intuitive name for something that doesn't use TLS, but instead HTTPS.
>> 
>> Indeed, I agree it is counter-intuitive! If I am starting a new project
>> I would probably call it nss-doh or nss-https.
>> 
>> > Is this really the best name for the package?  Could you explain the
>> > background behind the name?
>> 
>> The only reason right now is because it's the name used by upstream. I
>> choose to keep the current name and mention DoH in the description to
>> help search.
>> 
>> I plan to ask upstream author if they intend to support DoT in the
>> future then the name makes a little more sense. Otherwise if they can
>> change the name to nss-https or something else to avoid confusion.
>
> Would it make sense to resolve that with upstream before introducing this to 
> Debian?  It would save a trip through New and the confusion inherent in 
> package name instability.

The NSS mmodule is called “tls”:

| Then, add "tls" to the "hosts" entry in /etc/nsswitch.conf, before
| "dns" or anything else that contains "dns".

Renaming it would be a breaking change.  As long as the module has
this name, “nss-tls” does not seem inappropriate to me (although I
agree that it's not ideal).

Re: Source of shared runners containers used in salsa CI system

[Florian Weimer]

* Markus Frosch:

> On Wed, 2020-04-15 at 10:03 +0200, Emmanuel Kasper wrote:
>> I see salsagitlab ci is using docker containers for its shared runners
>> 
>> like for instance in
>> 
>> https://salsa.debian.org/cloud-team/debian-cloud-images/-/blob/master/.gitlab-ci.yml#L23
>> 
>> How are these containers images built ?
>> 
>> I specifically wanted to check if xz-utils is included or not in the
>> debian:buster image.
>
> That should be the standard docker images in Docker Hub's library:
> https://hub.docker.com/_/debian
>
> Source: 
> https://github.com/docker-library/official-images/blob/master/library/debian
>
> Tooling and artifact source (on GitHub) is linked there.
>
> You can just do:
> docker pull debian:buster

Are these Debian-produced images nowadays?

(Just because Docker says something is “official” doesn't mean that
the content is produced by the trademark owner.)

Re: What to do when DD considers policy to be optional? [kubernetes]

[Florian Weimer]

* Andrey Rahmatullin:

> Or you can look at the Redhat approach as a minimal working one.
> You know it can be done much easier and still work: in Redhat.

I think you are referring to a Fedora process, not a Red Hat process.
The Red Hat process does not seem much simpler than what ftpmaster are
doing, as far as I can tell.

Re: new kubernetes packaging

[Florian Weimer]

* Vincent Bernat:

>  ❦ 24 mars 2020 16:30 -07, Russ Allbery:
>
>> On the other hand (and I don't follow this community closely, so apologies
>> if I have the details wrong here), my impression is that the Go community
>> is not planning to support shared libraries, loves its staticly-linked
>> binaries, and makes extensive use of the fact that different packages can
>> pin to different versions and this doesn't matter for their intended
>> output format (a static binary).
>
> Go supports shared libraries since quite some time but I don't think
> it's widely used. Notably, the tooling around it is quite primitive.
> Even the plugin system (which is mostly like dlopen() and could be
> useful in many cases) is seldomly used.

That's true, but also somewhat besides the point because in order to
use dynamic shared objects to avoid recompilation of applications, you
also need practical ABI stability, both between compiler versions and
versions of the library.  Go does not have a low-level ABI that
remains unchanged across compiler versions, and (like C and C++) it
encodes struct offsets and sizes directly in the machine code,
sometimes in unexpected places due to inlining.  So even if the Go
standard library was linked as a shared object, you would still have
to rebuild all applications using it.

I believe GHC is similar in this regard.

Using shared objects under such circumstances only makes updates
harder for end users because live systems end up in inconsistent
states (ideally only for a brief time).

De-vendoring sources might still be an advantage because applications
can be fixed with a bin-NMU, but it's a lot of work.  The resulting
divergence from upstream can result in additional bugs.  On the other
hand, there are projects which bundle sources only for developer
convenience, but expect production binaries to use different library
sources for the dependencies.  I don't know if Kubernetes is one of
those projects.

Re: What to do when DD considers policy to be optional? [kubernetes]

[Florian Weimer]

* Paul Wise:

> On Tue, Mar 24, 2020 at 6:17 AM Vincent Bernat wrote:
>
>> Kubernetes is already using Go modules. They happen to have decided to
>> keep shipping a `vendor/` directory but this is not uncommon. It is
>> often considered as a protection against disappearing modules. So, there
>> is nothing to be done upstream. And BTW, there are currently 616
>> dependencies, pinned to a specific version.
>
> I wonder if the existence of Software Heritage could convince them
> disappearing modules aren't a problem, or if another service is
> needed.

The required versions of the modules could disappear from Debian, though.
Services like Software Heritage will not help with that.

Re: apt 2.0 release notes

[Florian Weimer]

* David Bremner:

> Julian Andres Klode  writes:
>
>>
>> apt install _toremove +toinstall
>>
>
> A common convention is to do something like
>
> apt install -- -toremove +toinstall
>
> I would prefer that to rolling our own syntax, unless there's some good
> reason (other than the small amount of extra typing)

It would also allow to use _ for purging packages.

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Eduard Bloch:

> I vaguelly remember that glibc keeps collecting workarounds for replaced
> APIs all the time, adjusting binary compatibility with manually
> redirected symbols. Glibc folks might correct me, though.
>
> So, wouldn't a restart of the i386 architecture under a different name
> give an excelent opportunity to get rid of many of such workarounds?

Yes, that's what happens automatically once you start a new
architecture for glibc, with a new ABI baseline.  All the compat
symbols before that baseline are automatically removed.

But for one of the largest pieces with unwanted ABI exposure (the
stdio implementation, also known as libio), we do not have a clean
replacement.  Part of the challenge is that even current gnulib pokes
at stdio internals, so it's not just about maintaining compatibility
with legacy binaries back when programmers didn't know you shouldn't
do that (or simply had no way to influence development of the system
libc).

Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib

[Florian Weimer]

* Ansgar:

> On Wed, 2020-02-19 at 09:39 +, Simon McVittie wrote:
>> On Wed, 19 Feb 2020 at 09:31:51 +, Simon McVittie wrote:
>> > I agree that what Guillem is proposing also does not have the property,
>> > which I think is one that is important to you?, that the contents of the
>> > root directory are decoupled from /usr (can be set up by an initramfs
>> > or a container-runner, perhaps in a tmpfs, without detailed knowledge
>> > of the OS installation in /usr).
>> 
>> Or perhaps Guillem is intending that in n years' time, when no package
>> in Debian (not even libc6!) ships files in /bin /sbin /lib* in its
>> data.tar.*, *then* the maintainer-script-maintained symlink farms in /bin
>> /sbin /lib* can be replaced by symlinks bin -> usr/bin, etc., without
>> this resulting in anything dpkg-managed being overwritten or aliased?
>> 
>> If that's the case, then we get that desirable property *eventually* under
>> this proposal, but not any time soon.
>
> As far as I know the path `/lib64/ld-linux-x86-64.so.2` is part of the
> ABI (and similar paths on other architectures). So that will have to
> exist unless we break the ABI. Therefore I assume this is unlikely to
> happen.

It doesn't have to be written to the file system under that name.  The
only thing that is required is that the kernel can open the dynamic
linker under the ABI-mandated pathname.

Re: Can Debian packaging changes require a CLA?

[Florian Weimer]

* Wouter Verhelst:

> On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote:
>> It would also make the package unmaintainable if the original packer
>> loses interest, so the package would not be suitable for inclusion in
>> a stable release.
>
> Eh, it doesn't?
>
> A CLA is "you're allowed to change this, but if you want us to accept it
> then you have to give us these rights, otherwise we'll reject your
> contribution".

Ordinarily, yes.

But I think here the request was that Debian would only make changes
(“packaging changes”) if they were made by someone who has been
subjected to a CLA.

Re: Can Debian packaging changes require a CLA?

[Florian Weimer]

* Andrey Rahmatullin:

> On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote:
>> It would also make the package unmaintainable if the
>> original packer loses interest, so the package would not be suitable
>> for inclusion in a stable release.

> Can you explain why do you think so?
> If a new maintainer wants to use a git repo to mainatin it, they can make
> a new one.

Only if the CLA requirement does not bind the Debian project.

Re: Can Debian packaging changes require a CLA?

[Florian Weimer]

* Scott Kitterman:

> On February 14, 2020 3:46:18 PM UTC, Dimitri John Ledkov  
> wrote:
>>Can a Debian Package Maintainer require CLA for accepting packaging
>>changes and distro patches to be uploaded into Debian itself?
>>
>>(case in point, debian maintainer & upstream wear the same hat, and
>>maintain upstream code & packaging on github.com, under a company org
>>with a CLA bot, rejecting debian/* merge proposals until CLA is
>>signed)

I don't see what's wrong with that.  Just because there's a debian/
directory doesn't make it Debian.

>>I didn't find things specifically about this in the policy and/or in
>>the dfsg-faq and the three classic tests (desert island / dissident /
>>tentacles of evil) do not fit the bill quite right.

> Maintainers have substantial discretion regarding what contributions
> they accept.  "I don't want a patch that's not upstreamable" is not
> uncommon.  Mostly your question seems to be a variant of that
> concern.

I tend to agree, but we do not have archive-level mechanisms to
enforce that and prevent NMUs.

Depending on the nature of the CLA, requiring it would border on a
DFSG violation.  It would also make the package unmaintainable if the
original packer loses interest, so the package would not be suitable
for inclusion in a stable release.

On the other hand, we have this in the request-tracker4 package:

# CONTRIBUTION SUBMISSION POLICY:
#
# (The following paragraph is not intended to limit the rights granted
# to you to modify and distribute this software under the terms of
# the GNU General Public License and is only of importance to you if
# you choose to contribute your changes and enhancements to the
# community by submitting them to Best Practical Solutions, LLC.)
#
# By intentionally submitting any modifications, corrections or
# derivatives to this work, or any other work intended for use with
# Request Tracker, to Best Practical Solutions, LLC, you confirm that
# you are the copyright holder for those contributions and you grant
# Best Practical Solutions,  LLC a nonexclusive, worldwide, irrevocable,
# royalty-free, perpetual, license to use, copy, create derivative
# works based on those contributions, and sublicense and distribute
# those contributions and any derivatives thereof.

I consider this an attempt at a CLA because of the asymmetric
licensing grant, but it's probably too weak for most people who care
about CLAs.

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Steve McIntyre:

>>In addition if we are using a new multiarch triplet, and need to
>>rebuild the world, are going to be ABI incompatible anyway, we might
>>as well use a proper multiarch-qualified ld.so pathname that does
>>not collide with anything.
>
> Hmmm. Moving ld.so is *hard* - we were already bitten by stuff here
> when we bootstrapped armhf initially. What we didn't know then (but
> know now!) is that the final element of the path (i.e. the filename)
> must be globally unique for glibc's code to work. We can't (for
> example) just move ld-linux-armhf.so.3 to a new directory, we'd have
> to rename the file itself. (Apologies if this is stuff you already
> know - I think it's worth explaining for others too!)

These changes also require updates to the ABI manual and upstream
patches to the toolchain.

I don't think Debian's multi-arch path changes have been properly
upstreamed yet, either.  Of course it does not help that key parts of
the GNU toolchain are more or less dead upstream; the lack of an
autoconf release is a real problem.

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Ansgar:

> Arnd Bergmann writes:
>> On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer  wrote:
>>> There's going to be a _TIME_BITS selector, similar to
>>> _FILE_OFFSET_BITS.
>>>
>>> There was a proposal to have only one API before, but I think the
>>> agreement was that it wouldn't save much complexity.
>>
>> It should be easy to force the _TIME_BITS selection by patching the
>> glibc headers in Debian though if we want.
>>
>> The problem with setting _TIME_BITS=64 only using dpkg-buildflags
>> but leaving the libc default at 32 bits is that anything that users build
>> themselves or that ignores the buildflags ends up with a broken ABI
>> when linking against one of the many libraries that expose time_t
>> in their ABI.
>
> It breaks the other way too:
>
> If you have an old library with a time_t in some public ABI, but an
> application using it sets _TIME_BITS=64, the headers suddenly define a
> different ABI from the one implemented by the compiled library.
>
> If you rebuild the library with _TIME_BITS=64, it changes ABI too and
> breaks reverse dependencies (ignoring special handling like libc does
> with versioned symbols). So you cannot just change it by default.
>
> I don't understand how this can work unless time_t is *never* exposed by
> any library other than libc.

Correct.  We have this problem with off_t today, which is used in some
header files.  The problem is particularly thorny because like
off64_t, time64_t will never be a standard type, so some projects
don't want to use it in headers.  And using time64_t would still be an
ABI break on i386.

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Ben Hutchings:

> On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
>> * Ben Hutchings:
>> 
>> > If I recall correctly, glibc *will* provide both entry points, so there
>> > is no ABI break.  But the size of time_t (etc.) exposed through libc-
>> > dev is fixed at glibc build time.
>> 
>> Is this a Debian-specific decision?
>
> I though that was the *upstream* decision, but perhaps that's still not
> decided after all?

There's going to be a _TIME_BITS selector, similar to
_FILE_OFFSET_BITS.

There was a proposal to have only one API before, but I think the
agreement was that it wouldn't save much complexity.

Re: Best practices for Debian developers who are also upstreams?

[Florian Weimer]

* Otto Kekäläinen:

> Is somebody else already doing something similar like this?

We are doing this with glibc in Fedora, which is not Debian, but kind
of similar.  We try to push all backportable fixes to the upstream
release branches (and master) and synthesize new pseudo-release
tarballs from those branches.  This means that (the equivalent of)
.orig.tar.xz reflects upstream contents, but necessarily an actual
release tarball.

This means that the set of downstream patches is reasonably small, and
grows only moderately due to ongoing bug-fixing.  In some cases, we
want to backport things into Fedora which do not seem appropriate for
upstream, and those end up as patch files.

The distribution packaging bits do not live in the upstream
repository, but we have special (glibc-specific) scripts which allow
us to merge in upstream changes (using git cherrypick and git rebase),
so this mostly a matter of training people to use these scripts.

I think this approach is only possible because we have stable release
branches upstream where we can backport the things we are interested
in (and other contributors are reasonably conservative), and we are
willing to respin the tarballs.  It simplifies matters for the
uploaders, but we cannot easily bisect individual changes/upstream
commits because they do not exist downstream, and the upstream
repository lacks the distribution customizations.

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Ben Hutchings:

> If I recall correctly, glibc *will* provide both entry points, so there
> is no ABI break.  But the size of time_t (etc.) exposed through libc-
> dev is fixed at glibc build time.

Is this a Debian-specific decision?

There has been a proposal upstream not to support 32-bit time_t for
new applications at all, but I don't think we will go in that
direction.

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Michael Stone:

> On Fri, Feb 07, 2020 at 02:46:19PM +0200, Wouter Verhelst wrote:
>>On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
>>> On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
>>> > Why not? This seems like the type of problem that SONAMEs are made for.
>>> > What am I missing?
>>>
>>> SONAMEs are set by the upstream developer in their build system
>>
>>Yes, I am aware of that, thank you. I meant to say that this feels like
>>something upstream could do a SONAME bump for.
>>
>>I'm wondering why they chose not to.
>
> You'd have to bump the soname for almost every library on the system.

And make sure that upstreams introduce per-architecture sonames,
otherwise we have soname bumps all across the board on 64-bit
architectures, too.

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Sam Hartman:

> Steve, you're presuming that we would not create a new soname for libc6
> on architectures where we want a new time ABI.

That seems to be a reasonable assumption because Debian would have to
use a different soname from upstream.  glibc upstream does not seem
likely to change soname for this at this point.

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Steve McIntyre:

> The kernel is *basically* fixed now. Internally, data structures
> should now be safe. There are a small number places where 32-bit time
> is still a thing, but it's in hand. A number of syscalls, ioctls,
> etc. have needed updates for the user-kernel interface level.

XFS is the elephant in the room, though.

> glibc is the place that needs to care about most of this.

I'm not so sure.  I really do not want glibc to parse and rewrite
ioctl arguments and return values, or ancillary socket data.

> The glibc folks have taken an interesting approach.
>
>  * 64-bit ABIs/architectures are already using 64-bit time_t
>throughout. The design is sane and so we should already be mostly
>safe here, modulo silly code bugs (we'll always have those!)

With the exception of utmp/utmpx, see __WORDSIZE_TIME64_COMPAT32 in
the headers.  Unfortuantely, this also affects on-disk data
structures.

>  * 32-bit ABIs/arches are more awkward. glibc will continue *by
>default* to use 32-bit time_t to keep compatibility with existing
>code. This will *not* be safe as we approach 2038.
>
>  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
>upwards, but this will of course affect the ABI. Embedded uses of
>time_t in libraries will change size, etc. This *will* be safe for
>2038.
>
> So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> need to basically rebuild the world to be 2038-safe.

The question is whether anyone wants an i386 port where this has
happened.

My opinion (professional in this case, even) is that i386 users want
compatibility with their binaries from 1998.  Otherwise they would
have rebuilt them for x86-64 by now.  Under this worldview, i386 is
for backwards compatibility with existing software.  Users will want
to run these old programs in a time namespace with shifted time, too.

There is also substantial commercial interest in those old binaries
(which becomes apparent when you break glibc compatibility with them
8-/).

>  B Decide which 32-bit ports we expect to care about by 2038, and
>re-bootstrap new versions of those ports *with different
>names*. This would allow most of our developers to ignore the
>problem here (as 64-bit arches are not affected) and let a smaller
>number of people re-bootstrap with new ABIs with 64-bit time_t
>embedded. There are some downsides here:
>
>* we would end up with two versions of some ports for a short time
>  - probably one release of overlap
>
>* users would *not* be able to simply upgrade from one to the
>  other, due to lack of binary compatibility
>
>We *would* be able to run old and new ABIs on top of the same (new
>enough) kernel (e.g. for buildds), so a lump of this would just be
>simply building the new world and filing bugs where needed.
>
>We'd need to decide exactly which of our 32-bit ports we would want
>to do this path with (probably armhf->arhmft?, maybe
>armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
>continuity, we will most likely *not* end up with a different
>visible ABI via the triplet and the runtime linker, so old/new
>multi-arch will be impossible.

Yes, it really has to be B for i386 at least.

The other issue is that the Y2038 work has tentacles everywhere.
Porting to new architectures (whether they are 32-bit or 64-bit) will
require additional changes to those applications which make direct
system calls, in some cases even if they do not even use time_t or
struct timespec with those system calls at all.  For example, new
ports will not define __NR_futex, only __NR_futex_time64.

Accepted debsecan 0.4.20.1 (source) into unstable

[Florian Weimer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 21 Jan 2020 21:13:26 +0100
Source: debsecan
Architecture: source
Version: 0.4.20.1
Distribution: unstable
Urgency: low
Maintainer: Florian Weimer 
Changed-By: Florian Weimer 
Changes:
 debsecan (0.4.20.1) unstable; urgency=low
 .
   * Source-only upload for testing transition.
Checksums-Sha1:
 9e771adb0cfe32163754696bb70fc619157ac9a6 1240 debsecan_0.4.20.1.dsc
 7b7640321c281dc723473012b5bf95dc392c7663 57888 debsecan_0.4.20.1.tar.xz
 76b21a3e0143d06bc6025bfe3bda6cbf18cf348c 5181 debsecan_0.4.20.1_amd64.buildinfo
Checksums-Sha256:
 2d0c36b01a8233fec0f89d6a127b6659f5eeb81fccaa4c58074365898144e5a3 1240 
debsecan_0.4.20.1.dsc
 305cd786b391bf41bc3dd5f3cdf16e12640a2e55d2a30c6514a25535716e1dcc 57888 
debsecan_0.4.20.1.tar.xz
 92735ac21a94173785f654f802e289eb61e4507df02a5c374d746104c3275372 5181 
debsecan_0.4.20.1_amd64.buildinfo
Files:
 6ad6d672ba8127262f1a00508dc7c240 1240 admin optional debsecan_0.4.20.1.dsc
 fa93d716702f1ed4cf49cf4112fd26d0 57888 admin optional debsecan_0.4.20.1.tar.xz
 468065a5441884088bf6af80cacb0941 5181 admin optional 
debsecan_0.4.20.1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEyNPZz/qecFY/MvpUv3v/BALVJL4FAl4nXsAACgkQv3v/BALV
JL6w6gf+JSTYyK4tSnfGRxitzr7+x1DJve0mGGhjf2vWfWIMZquaxT2r+vxdP9N8
UcmZ5XeargRQmPzXEX5d82vPAJ5huyP5kay+3T+YhpwrCqaGbLv1txMQfMPC5+t/
cUNLoFuudyrGI4e7R4ryscDsWVLPEpt5tYxDxg2EjxFfK2tYeWUxvuLamZIq2dR1
1KvYHwL54GDdbNfsq02X3zGFUuukC80a8EA4zsLpE5Ye9ymj3Rq3yl0qyjlTR++A
FTtwz+UAQdA86RrTY5XNIHOs99clcZqjaNl4Bo6iY96l8braHhsUyDxxTM7vSjBA
n00oW7RphwZCCaBi5h9mJZuJCrMu1w==
=RUrq
-END PGP SIGNATURE-

Re: Secureboot: how to use MOK

[Florian Weimer]

* Steve Langasek:

>> and this is the reason we have to require all modules to be signed by
>> default.
>
> Enforcement of kernel module signatures is part of what's called the
> "lockdown" featureset.  It is optional, and not a requirement from
> the UEFI spec,

The requirement is in the Microsoft signing policy (or the document
that comes closest to such a policy):

|  b. Developers might assume that secure boot security requirements
|  have been satisfied when their initial boot is complete. However,
|  if a secure boot system permits launch of another operating system
|  instance after execution of unauthenticated code, the security
|  guarantee of secure boot is compromised. If this vulnerability is
|  exploited, the submission might be revoked.



Admittedly, that part isn't entirely clear. I think most vendors have
an escape hatch to load unsigned kernel modules even in secure boot
mode, without a reboot or physical presence check.

Accepted debsecan 0.4.20 (source all) into unstable

[Florian Weimer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 27 Oct 2019 21:31:32 +0100
Source: debsecan
Binary: debsecan
Architecture: source all
Version: 0.4.20
Distribution: unstable
Urgency: low
Maintainer: Florian Weimer 
Changed-By: Florian Weimer 
Description:
 debsecan   - Debian Security Analyzer
Closes: 800115 866921
Changes:
 debsecan (0.4.20) unstable; urgency=low
 .
   * Port to Python 3, using a patch from Michael Gilbert.  Closes: #800115.
   * Recommend cron-daemon as an alternative to cron.  Closes: #866921.
   * Switch to debhelper 12 and Standards-Version 4.3.0.
Checksums-Sha1:
 c024de7aaacd9b0adcd1434dd71a8a5a60f9f813 1232 debsecan_0.4.20.dsc
 85d1f2127e3d754c49c1ebd69c32ec961553b774 57844 debsecan_0.4.20.tar.xz
 5661a31144deaccdcd8945d433b50c31053e501b 33132 debsecan_0.4.20_all.deb
 3be3ef1a0a293f374c8cdab59a4ac307aa64f7ac 4999 debsecan_0.4.20_amd64.buildinfo
Checksums-Sha256:
 21c92301a4735d960765e0aacc987be770a05f5cf32ced50d08419b559b1660c 1232 
debsecan_0.4.20.dsc
 2cd30276672d47b6c0f6428165855e2e39af2cf9745603cbbea17d68093f37b3 57844 
debsecan_0.4.20.tar.xz
 e13afb864864e0809c06ee83cfca121ac68a32f2175dc36c7d39709a8e7cc49c 33132 
debsecan_0.4.20_all.deb
 842c3882772ca0587b3361c16dcab6f6e882c107ce58e25d03e6677b0c16a2b4 4999 
debsecan_0.4.20_amd64.buildinfo
Files:
 e0068c38776aceda85655febf994e03d 1232 admin optional debsecan_0.4.20.dsc
 cd1bc45762df494d8a80a6fcf92836df 57844 admin optional debsecan_0.4.20.tar.xz
 c2d1efe5b4895ad16175d7b9287a42f1 33132 admin optional debsecan_0.4.20_all.deb
 6b23898ba7902db8f6d64e770a08b4f3 4999 admin optional 
debsecan_0.4.20_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEyNPZz/qecFY/MvpUv3v/BALVJL4FAl22AR0ACgkQv3v/BALV
JL7GYwf/RtZxLo1PKN5Q3aO9s+aAA1QE8fTYhILrHslQe5wJ5H9njlO2ar2FeZ5j
8kGTyKGer0OBSJYLT1ry/JL3PMDfdEcRAEtJ5AmrA3yvioXjd15z4mOr4Gsls66W
lUcY0r/kezDMCt/2vXtruF2Ndt18a2WazgRGarIeUULB0guLg+a9DrNyjeox9f9z
AIUlKUuyLjShe8nm6EPfM79pkKdqsLoyojjUyPHiJh6NWmuWTV1FHbtz5S3/7OMm
cXewdE3poGl9hktrbC1Fy1rS2QRDgPIrQQxs0zC0tIrGL59nhPcPxQgiuw2W5HCb
VmbxmB8Yc6Z1SAht0i4FiHtgiwopgw==
=Bk9J
-END PGP SIGNATURE-

Re: Secureboot: how to use MOK

[Florian Weimer]

* Thomas Goirand:

> I've setup my new laptop with secureboot, and now, I can't use the DKMS
> modules from Virtualbox, as they aren't signed. I've been told by Sledge
> that I should use MOK to do that, and that DKMS packages are supposed to
> have all in them to support MOK.

I don't think secure boot provides any benefit at all if you store the
kernel module signing key on the same machine.

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Florian Weimer]

* Philipp Kern:

> It is probably worth pointing out that Firefox's use of Cloudflare's DoH
> endpoint is governed by a different policy outlined here:
>
> https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/

Thanks.

> Per that policy, other third parties can only get the data with
> Mozilla's written permissions. And APNIC (or any other third party) is
> not mentioned.

But isn't that policy less restrictive that the other, once Mozilla
has given permission?

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Florian Weimer]

* Robert Edmonds:

> The entire DNS root zone is only 1 MB compressed and is updated about
> once a day. It would be even better for privacy if the whole root zone
> were distributed via HTTPS, as the initiator would not reveal to the
> server any information about what TLD is being looked up.
>
> There are currently ~1500 TLDs in the root zone. Dividing 1 MB by the
> number of TLDs, this is ~700 bytes per TLD, which is roughly the amount
> of bandwidth required by a query/response pair of UDP DNS packets to
> obtain the delegation for a TLD.

Or you can turn on query minimization and NSEC-based NXDOMAIN
synthesis, at which point there is hardly any privacy leak left.

The challenge with the root zone is that anyone can become a de-facto
root server operator for their own part of the Internet (at least with
physical control over machines), by inviting some of the established
operators to host an anycast node on their network.  It's very
difficult to guarantee privacy in such a widely distributed system.

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Florian Weimer]

* Adam Borowski:

> Let's compare; by "ISP" I mean every hop on the network path.
>
> With local DNS:
> * the target server knows about you (duh!)
> * the ISP can read the destination of every connection
>   [reading the DNS packets, reading the IP header, reading SNI header]
> * the ISP can block such connections
>   [blocking DNS packets, blocking actual connection]
> * DNSSEC forbids falsifying DNS
>
> With DoH:
> * the target server knows about you (duh!)
> * the ISP can read the destination of every connection
>   [reading the IP header, reading SNI header]
> * the ISP can block such connections
>   [blocking actual connection]
> * Cloudflare can read the destination of every connection
>   [they serve the DNS...]
> * Cloudflare can falsify DNS¹
> * Cloudflare can block connections
>   [blocking or falsifying DNS response]
>
> So currently DoH is strictly worse.

Furthermore, you don't have a paid contract with Cloudflare, but you
usually have one with the ISP that runs the recursive DNS resolver.

If you look at 

  

you will see that the data is shared with APNIC for “research”:

| Under the terms of a cooperative agreement, APNIC will have limited
| access to query the transaction data for the purpose of conducting
| research related to the operation of the DNS system.

And:

| Specifically, APNIC will be permitted to access query names, query
| types, resolver location



Typically, APNIC will only see a subset of the queries if you use your
ISP's DNS resolver (or run your own recursive resolver).

Cloudflare only promises to “never sell your data”.  That doesn't
exclude sharing it for free with interested parties.

(Some people may find it amusing that I'm concerned by this because I
opened that particular can of worms fifteen years ago.)

Re: Options for 64-bit time_t support on 32-bit architectures

[Florian Weimer]

* Simon McVittie:

> On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote:
>> Remaining usecases of i386 will be old binaries, some old Linux binaries 
>> but especially old software (including many games) running in Wine.
>> Old Linux binaries will still need the old 32bit time_t.
>
> Based on background from my contributions to the Steam Runtime:
>
> I don't have numbers, but you might be surprised how many Linux-supporting
> games are 32-bit. The Steam client itself is currently also 32-bit
> (with some 64-bit subprocesses); this is somewhat deliberate, to act as
> a canary for whether 32-bit code works at all, particularly when combined
> with graphics.
>
> The Steam Runtime (a LD_LIBRARY_PATH library bundle used to run Steam and
> Steam games) is built on an increasingly ancient version of Ubuntu, but
> it tries to use newer libraries of the same SONAME from the host system
> where available, which they often will be, because people who install
> Steam probably also install Wine, which has 32-bit dependencies. If those
> libraries have an incompatible ABI involving 64-bit time_t, and it is used
> at the ABI "surface" between a host-system library and a Steam Runtime
> library or the game, then 32-bit games, and the Steam client itself,
> will crash.

We could in theory bump soname for these libraries, but that has the
unfortunate side effect that it will likely leak to 64-bit
architectures, creating more work for everyone.

I don't see a good way to maintain those libraries with a single-ABI
approach.  So if that's an important use case, it would be a fairly
strong case against it, I think.

Re: Options for 64-bit time_t support on 32-bit architectures

[Florian Weimer]

* Adrian Bunk:

> On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote:
>> * Adrian Bunk:
>>...
>> For comparison, the original plan was to provide a macro, perhaps
>> -D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI
>> set is used (“dual ABI”).
>
> To me this would sound like more trouble than a clear break,
> similar to the mostly working dual OpenSSL 1.0 and 1.1 support
> in stretch.

Could be.  But it would enable keeping i386 at the old ABI while still
building the distribution with newer glibc versions with current
kernel headers (the libc-alpha discussion is evolving regarding the
precise nature of the enablement approach).

Other 32-bit architectures could opt to do the transition now.

>> Similar to the LFS support, with the
>> additional property that binaries built in either mode should continue
>> to work on kernels which predate support for the *_time64 system
>> calls.
>
> Debian does not support running on kernels older than the one in the
> previous stable release.
>
> E.g. Qt in Debian 9 unconditionally uses the getrandom syscall that is 
> not in kernel 3.16 in Debian 7.

The 64-bit system calls arrived in Linux 5.1, so I think the fallback
will be needed for quite some time.

Re: Options for 64-bit time_t support on 32-bit architectures

[Florian Weimer]

* Adrian Bunk:

> [ only speaking for myself ]
>
> On Thu, Jul 18, 2019 at 11:05:53PM +0200, Florian Weimer wrote:
>>...
>> The consequence is that in order to build 32-bit-time_t libraries
>> (Gtk, for example), an old glibc needs to be kept around.  In
>> practice, it would probably mean that it is impossible to maintain a
>> set of 32-bit-time_t libraries in a classic distribution build
>> environment (with a unified buildroot and native builds).
>>...
>> Do you want to build 32-bit libraries (besides glibc) which are
>> compatible with legacy applications, with a 32-bit time_t, in the
>> future?  Or is a world where time_t is pretty much always 64 bit
>> something that would be acceptable?
>
> So this is an ABI-incompatible change that would result in new Debian 
> architectures, similar to arm (OABI), armel (EABI softfp) and armhf 
> (EABI hardfp) being different Debian architectures for 32bit little 
> endian ARM?

Not quite.  glibc would still be able to run binaries from the old ABI
and the new ABI.  But under the proposal, you would have to use an old
glibc (missing new system call wrappers etc.) if you want to build
libraries that provide interfaces involving 32-bit time_t.

So in practice, it would likely mean a new Debian architecture, or a
de-facto ABI bump for i386 and armhfp.

For comparison, the original plan was to provide a macro, perhaps
-D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI
set is used (“dual ABI”).  Similar to the LFS support, with the
additional property that binaries built in either mode should continue
to work on kernels which predate support for the *_time64 system
calls.  The should also use the vDSO as before.  All these
requirements make an implementation quite hairy, hence the desire for
simplification.

> There are two current release architectures where it is at least 
> imaginable that they will still be around closer to the year 2038:
> i386 and armhf

Right.

> For i386 the last newly released 32bit-only hardware were some early
> Intel Atoms 10 years ago, and when the AMD Geode goes out of production
> soon there might be no hardware in production left.
> There are still surprisingly many people using Debian on 32bit-only
> hardware, but in 20 years this will have changed.

You have thankfully edited out the Intel Quark. 8-)

> Remaining usecases of i386 will be old binaries, some old Linux binaries 
> but especially old software (including many games) running in Wine.
> Old Linux binaries will still need the old 32bit time_t.
> Which options are viable from a Wine point of view?

I talked to a Wine developer in the office, and Wine doesn't directly
expose the time_t ABI to Windows binaries (which isn't suprising).
It's also already been ported to 32-bit systems with a 64-bit time_t.
I expect that this is not a determining factor.

> For armhf new hardware might be available long enough to come close
> to the year 2038, this might require a new architecture at some point.

The push for a 64-bit time_t definitely comes from the embedded 32-bit
processor direction.

For glibc, providing a dual ABI configurable at build time one or all
32-bit architectures probably does not make much of a different in
terms of overall effort.  This means that if we need to produce the
dual ABI for i386, armhfp will likely get it as well.

Options for 64-bit time_t support on 32-bit architectures

[Florian Weimer]

There is an effort under way to enhance glibc so that it can use the
Y2038 support in the kernel.  The result will be that more 32-bit
architectures can use a 64-bit time_t.  (Currently, it's x86-64 x32
only.)

Originally, the plan was to support both ABIs in glibc for building
new applications, similar to what is currently possible with
-D_FILE_OFFSET_BITS=64 for changing the size of off_t.  However, this
turned out to be difficult to implement, and so far, no one has posted
patches which appear to be reasonably correct and complete.

The latest proposal is a single-ABI mode for development:

  

Old binaries with a 32-bit time_t will continue to run, but new
binaries built against a current glibc will always use a 64-bit time_t
under this approach.

The consequence is that in order to build 32-bit-time_t libraries
(Gtk, for example), an old glibc needs to be kept around.  In
practice, it would probably mean that it is impossible to maintain a
set of 32-bit-time_t libraries in a classic distribution build
environment (with a unified buildroot and native builds).

I do not have a strong opinion about this because I personally do not
care about 32-bit architectures at all (sorry).  I would like to
solicit Debian's feedback on this matter.

Do you want to build 32-bit libraries (besides glibc) which are
compatible with legacy applications, with a 32-bit time_t, in the
future?  Or is a world where time_t is pretty much always 64 bit
something that would be acceptable?

Re: Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another

[Florian Weimer]

* Nicholas D. Steeves:

> Package name: fuidshift
> Version : 3.0
> Upstream Author : Name 
> URL : https://github.com/lxc/lxd/tree/master/fuidshift
> License : Apache 2.0
> Programming Lang: Go
> Description : remap a filesystem tree to shift one set of UID/GID
> ranges to another
>
> Fuidshift is useful for converting privileged containers to
> unprivileged ones, and also to adapt a container master to multiple
> users' authorised subuid and subguid ranges.  It also sounds like it
> might be useful for fixing up cases where --numeric-owner should have
> been used, but where it would be too labour-intensive to manually chown.
>
> I learned about this tool via the following document:
>   https://github.com/BenSartor/unprivileged-lxc-containers
>
> Here is the upstream description:
>
>   This tool lets you remap a filesystem tree, switching it from one
>   set of UID/GID ranges to another.
>   This is mostly useful when retrieving a wrongly shifted filesystem tree
>   from a backup or broken system and having to remap everything either to
>   the host UID/GID range (uid/gid 0 is root) or to an existing container's
>   range.
>   A range is represented as 
> :::.
>   Where "u" means shift uid, "g" means shift gid and "b" means shift
> uid and gid.
>
> https://github.com/lxc/lxd/blob/81b81b9ace3064c8065319f4e984378244587d80/fuidshift/main_shift.go#L26-L36
>
> It's part of the LXD project, but I'm not sure if it's as difficult to
> package as LXD itself, which is one reason why I've CCed the Go team.
> I also wonder if the best way to get this into Debian would be a
> src:lxd that produces bin:fuidshift.

How does this compare to (or interact with) newuidmap and newgidmap
from uidmap?

There's a push to force uidmap on everyone, with tight integration
into NSS.  If there's a competing scheme, it would be helpful to know
about it.

Re: How to deal with meaningless SOVERSION bumps from upstream?

[Florian Weimer]

* Mo Zhou:

> I realized that it's too late to ask the upstream to revert the
> SONAME bump.

If upstream is okay in principle with changing soname, it's not really
too late, ever.

Re: How to deal with meaningless SOVERSION bumps from upstream?

[Florian Weimer]

* Sam Hartman:

> There's fairly significant advantages to keeping ABI consistent with
> upstream when possible.
> So, unless the Debian ABI has diverged from upstream already, I'd
> recommend that you track the soname change and accept the rebuilds
> post-buster.

It's possible to support both sonames using a symbolic link.  ld.so
will only load the library once, adding the other soname as an alias.

The question then becomes which should be the default.  Probably the
newer one, for the reason you outlined.

Re: How to deal with meaningless SOVERSION bumps from upstream?

[Florian Weimer]

* Mo Zhou:

> Should I bump the SOVERSION and trigger a transition after the Buster
> release? (I think it's pointless, as it triggers pointless rebuild for
> many packages including Qt) Or ignore the upstream SOVERSION bump and
> track the changes by myself?

I've been able to convince libidn2 to revert a soname bump recently.
Maybe this would be an option for double-conversion, too?

Re: Mass bugfiling potential: bundled implementation of md5

[Florian Weimer]

* Adrian Bunk:

> On Thu, Oct 25, 2018 at 02:56:23PM +0800, Yangfl wrote:
>> Hi,
>> 
>> Many of packages include bundled Aladdin Enterprises independent
>> implementation of md5. Full list can be seen at
>> https://codesearch.debian.net/search?q=typedef+unsigned+char+md5_byte_t=1
>> (100 packages)
>> 
>> As discussed in #909116, libmd-dev now provides a compatible interface
>> for that, so bundled sources should be dropped.
>>...
>
> What exactly are the benefits?

You can use Systemtap or LD_PRELOAD to detect remaining uses of MD5.
(Well, one implementation of it at least.)

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

[Florian Weimer]

* Mo Zhou:

> Proposal:
>
>   * The "-ilp64" postfix should be appended to the SONAME of all the new
> shared objects that provide ILP64 interface. For example:
>
>   libblas.so.3 (LP64) -> libblas-ilp64.so.3 (ILP64)
>
> As a result, the same postfix should be added to the binary package
> name. For example:
>
>   libblas3 (LP64) -> libblas-ilp64-3 (ILP64)
>
>   * No change will be made to all the present BLAS/LAPACK libraires that
> provide LP64 interface.
>
>   * No change will be made to either API or ABI of BLAS/LAPACK.
>
>   * This proposal only applies to 64-bit-capable architectures.

Why do you want to retain the libraries with 32-bit indices?  Is it
for ABI compatibility with Fortran code that uses them directly?

What's the time frame for these changes?  Is it likely that a Fortran
ABI bump occurs before that anyway?

Re: "debian.pool.ntp.org" for Debian derivatives?

[Florian Weimer]

* Ian Jackson:

>> PS: Paying that extra money to ntp.org would certainly not kill use, but
>> adding that money instead to our currently already existing support of
>> Debian-LTS / DebConf sponsoring / ... would probably benefit a lot more
>> Debian (downstream) users and developers.
>
> I wasn't aware that they charged commercial entities in this kind of
> situation but that seems reasonable to me.  IDK how much the charge
> is.  You are getting a service from pool.ntp.org, and as a commercial
> entity you should pay your suppliers.

Just to be clear: the fee goes to the pool operator, not the server
operators.  The actual service is donated without an expectation of
compensation, or the compensation is kind, say for enabling network
mapping and port scanning of IPv6 hosts.

Re: Asciidoc transition to the python3 implementation or just EOL

[Florian Weimer]

* Joseph Herlant:

> Hi guys,
>
> As announces a while ago in #895462, the asciidoc package which only
> support python2 is officially EOL.
>
> Notes:
> * The python 2 implementation of asciidoc which, for now, lives at
> https://github.com/asciidoc/asciidoc won't receive any new updates
> * The python 3 implementation that lives at
> https://github.com/asciidoc/asciidoc-py3 started to have a working
> version

There is a second Python 3 port here:

   

I don't know which one is better, and if both support Unicode properly
(the old asciidoc did not, but given the name, that can hardly be
considered a bug, right?).

> 3. have people just move to asciidoctor (it's way more actively
> maintained and tested, plus, most package support both nowadays) and
> just let the python implementation die naturally

Ah, right, I was about to suggest that.

Re: Limiting the power of packages

[Florian Weimer]

* Simon McVittie:

> On Thu, 04 Oct 2018 at 08:34:15 +0200, Florian Weimer wrote:
>> * Paul Wise:
>> > To fully solve the problem you need a whitelist based approach that
>> > ends up something completely different like Flatpak.
>> 
>> Flatpaks don't work this way.  Try installing gedit and open a file
>> like ~/.ssh/id_rsa with it.  There are no security prompts whatsoever,
>> yet the software in a flatpak can read your SSH private key.
>
> That particular app's whitelist presumably includes "share the entire
> host filesystem"; the existence of a whitelist doesn't mean the whitelist
> isn't large. General-purpose development tools and text editors generally
> have larger whitelists than more limited apps, with GNOME Builder at
> the extreme of least-confined.

The other problem is that the whitelist comes from the application
author, so it's like asking a drunk whether they are drunk.

> % flatpak --user install flathub org.gnome.gedit
> Installing in user:
> org.gnome.Platform.Locale/x86_64/3.28 flathub 2823e3d81b74
> org.gnome.gedit/x86_64/stable flathub a03b66681bce
>   permissions: ipc, wayland, x11
>   file access: host, xdg-run/dconf, ~/.config/dconf:ro
>
> \- this is why it can read arbitrary files
>   dbus access: ca.desrt.dconf, org.gtk.vfs.*
> org.gnome.gedit.Locale/x86_64/stable  flathub c2974b37ef08
> Is this ok [y/n]:
>
> I think the intention is that GUIs like GNOME Software prompt for apps
> that need special permissions in a more user-friendly way, something
> like how Android handles app permissions, although I don't think that's
> actually implemented yet.

Yes, I tried this on Fedora 28 before posting, which I consider the
reference implementation.  There is no security prompt at all.

I've also been told in an other context that it is up to the Flatpak
repository to vet the permissions requested by the software authors.
This model would be closer to what the Debian archive does in
practice.

> I don't know specifically why gedit has the host file access
> permission: it's unnecessary for File->Open and File->Save
> As... (e.g. org.gnome.Recipes is a good example of an app that
> doesn't, but can still import and export recipes) but presumably some
> of gedit's IDE-like features involve opening files other than the one
> you directly asked for.

I assume it's because gedit creates backup files when saving, and the
document portal does not support that.

Re: Limiting the power of packages

[Florian Weimer]

* Paul Wise:

> To fully solve the problem you need a whitelist based approach that
> ends up something completely different like Flatpak.

Flatpaks don't work this way.  Try installing gedit and open a file
like ~/.ssh/id_rsa with it.  There are no security prompts whatsoever,
yet the software in a flatpak can read your SSH private key.

salsa.debian.net

[Florian Weimer]

I received some key SSH import notices from salsa.debian.net, but I
didn't request anything.

Is this harmless, or is something fishy going on?

Re: User-installable Debian packages?

[Florian Weimer]

* Steffen Möller:

> The HPC community does not want to need root privileges to get their
> software installed/used on the HPC setup. This excludes regular
> Debian packages, traditional containers like Docker and chroot
> environments.

So they would rather give the user full file system access on an
unprotected host, with a shared /tmp and /proc, limited control over
resource utilization, at least a few SUID programs, and the ability to
become root once you have obtained the password from someone?

Under the alternative model, users do not get any access whatsoever to
the actual host, are always confined to containers, and do not have
root rights in the container, either.  True, the container setup
requires elevated privileges, but this is tightly controlled by the
container management engine.  It's not something the user would run
after logging into the host over SSH.

For shared computing resources, the container model seems vastly
superior to user-based separation.  I'd be concerned about the
overhead, but I really don't understand the objection that this
requires root privileges when those privileges can be tightly
controlled.

(I'm not saying that Docker, OpenShift & Co. are suitable for HPC
environments.  They probably are not, but Linux namespaces & cgroups
seem quite appropriate for such environments.)

Re: User-installable Debian packages?

[Florian Weimer]

* Simon McVittie:

> On Sat, 22 Jul 2017 at 12:28:04 +0200, Steffen Möller wrote:
>> And quite some packages in our
>> distribution do not really need to be installed as root if they were
>> installed where the user has write permissions. There would hence be
>> little overhead over what we have now. Should we not somehow find ways
>> to tag any such location-agnostic packages and prepare dpkg for
>> installing e.g. in $HOME/.debian when it is executed as non-root?
>
> Rather than inventing a new wheel and having another Debian-specific
> thing that can only be used on Debian (and not even on derivatives
> without it being a "Frankendebian" system), might it be better to use
> Debian's source, binaries or a mixture of the two as input to creating
> something cross-distribution like Flatpak, AppImage or Snap? I would
> personally recommend Flatpak.

But it's not clear if the HPC community wants to run
containers/namespaces at all.  Maybe Steffen can comment.

Re: Clearing the conffile status of a file

[Florian Weimer]

* Sven Joachim:

> On 2017-07-12 09:56 +0200, Florian Weimer wrote:
>
>> I've got a request to remove the conffile status of a file after it is
>> no longer a conffile.  dpkg-maintscript-helper rm_conffile does not
>> seem to do this, based on the documentation and the source code.
>>
>> Is there a clean way to implement this (i.e., by not patching
>> /var/lib/dpkg/status directly)?
>
> AFAIK the only method, and not a pretty one, that works from package
> maintainer scripts is to rename the file in the preinst and rename it
> back in the postinst.  Plus all the error handling required (e.g. if
> unpacking fails), where dpkg-maintscript-helper would at least take care
> of the gory details[1] for you.

> 1. https://wiki.debian.org/DpkgConffileHandling

Oh, I assumed that this was only about preserving the file, and it
would not affect the state as a conffile as such (except that the file
would be gone).

> My choice would probably be to leave the conffile alone, at least until
> dpkg itself is able to take care of the problem[2].

> 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822462

That makes sense, thanks.

Clearing the conffile status of a file

[Florian Weimer]

I've got a request to remove the conffile status of a file after it is
no longer a conffile.  dpkg-maintscript-helper rm_conffile does not
seem to do this, based on the documentation and the source code.

Is there a clean way to implement this (i.e., by not patching
/var/lib/dpkg/status directly)?  If there is a way, is there a reason
not do it?

Accepted debsecan 0.4.19 (source all) into unstable

[Florian Weimer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 02 Jul 2017 12:31:29 +0200
Source: debsecan
Binary: debsecan
Architecture: source all
Version: 0.4.19
Distribution: unstable
Urgency: medium
Maintainer: Florian Weimer <f...@deneb.enyo.de>
Changed-By: Florian Weimer <f...@deneb.enyo.de>
Description:
 debsecan   - Debian Security Analyzer
Closes: 749424 789196
Changes:
 debsecan (0.4.19) unstable; urgency=medium
 .
   * Add support for stretch and buster, using patches from Michael
 Stapelberg and Salvatore Bonaccorso.  Closes: #789196
   * Python needs https_proxy for proxy configuration with https:// URLs.
 Apply patch from Michael Stapelberg.  Closes: #749424
   * Update project URLs.
Checksums-Sha1:
 f827db03c5d0e53165b05d76c8a263a4c03061b5 1189 debsecan_0.4.19.dsc
 53fbcc90e2a9912edc2658c7468b2b4ce274af3d 75690 debsecan_0.4.19.tar.gz
 96786a98dbe88c692666af148254b3d41d5d79dd 34952 debsecan_0.4.19_all.deb
 844baa8f0041003b9a80dee21fe2f658f2e81433 4460 debsecan_0.4.19_amd64.buildinfo
Checksums-Sha256:
 416df7b248b82744c33252f9e95c3233a4c4ca4e9609ce0af5fa4a755de73cb7 1189 
debsecan_0.4.19.dsc
 43ff88e69da2b06ce956159ce3fbb9dc6737e8c911d972bd1fe5f13d95f06cf2 75690 
debsecan_0.4.19.tar.gz
 01fa41cc32bcc35fdef49720b68db1fffb7e162b29298181c1da0fef89adc0e2 34952 
debsecan_0.4.19_all.deb
 3e32e78075ebd1412f3d4bd6f119027e277229e4080f1bdd74beae135f442b7f 4460 
debsecan_0.4.19_amd64.buildinfo
Files:
 35ffea6086e4b9c2af2315b9aa1f8dde 1189 admin optional debsecan_0.4.19.dsc
 29750c65ca17bb40622b7a58e99e75d5 75690 admin optional debsecan_0.4.19.tar.gz
 467eb70da7a69404bd4cf29c82bb210a 34952 admin optional debsecan_0.4.19_all.deb
 0b39c496586324e0e51019c89a7a847d 4460 admin optional 
debsecan_0.4.19_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEyNPZz/qecFY/MvpUv3v/BALVJL4FAllZQgcACgkQv3v/BALV
JL6zOgf+ONdkY5DFx8pVDcEPrmxU7uXWz/2qNyfUAtwrSxS1x+Yq1yBjnEXsjCyi
2597JnysuH8H/OWmIvAfhikOrVqva6h6EsftZypJciSFblkMjBNRTe9yL6gWUoIH
p4t9BtjeT36TyrQnr7VJ/K7CKGMdWUyOQkob60KYcZmwuLUi8wut8wFXyqjlxbpP
OOb7ZcKJcngdIBtybRIL3VsTBpJGNIv/42KVxG3APdmucQe2Y1ctRqc5dDlccw12
tRdnv2K3Md8H2+AsNiXX3gsPTaCkuoCP64TiVEGtzbwSX4YW/6HFdyxpYqoSnYFg
j+sLbWhVZU7ImDViXBYjzOwcuH+1rw==
=EDeM
-END PGP SIGNATURE-

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

[Florian Weimer]

* Ben Hutchings:

> On Mon, 2017-06-26 at 08:34 +, Holger Levsen wrote:
>> On Sun, Jun 25, 2017 at 09:19:36AM -0300, Henrique de Moraes Holschuh wrote:
>> [...]
>> > Apparently, Intel had indeed found the issue, *documented it* (see
>> > below) and *fixed it*.  There was no direct feedback to the OCaml
>> > people, so they only found about it later.
> [...]
>> so in conclusion: don't buy intel. At least in future.
> [...]
>
> Other procesors aren't bug-free, they just don't get as many bug fixes.

And the fixes aren't documented publicly at all.

Re: System libraries and the GPLv2

[Florian Weimer]

* Philip Hands:

> P.P.S. Does anyone really expect a consensus to emerge where we decide
> to ignore the exception to the exception across the board without
> consulting lawyers?  I think there are several people in this thread
> (myself included) that have demonstrated that they're going to argue
> against such a consensus.  That being the case, it's not going to
> happen, so repeating the same justifications for why there is no problem
> does not seem even slightly productive to me.

I think we can use the discussion in the thread to determine what we
want from the lawyers, should we eventually decide to consult them.

I think it is far more likely to have a constructive discussion with
counsel if we tell them from the start that we want to ship GPL
software as part of Debian which links against libraries such as
current libgcc (for GPLv2 software) and OpenSSL, asking for advice
what is needed to make this happen while minimizing risk for Debian
and downstreams.

I hope we can at least get consensus that this is still the goal we
are after.

Re: System libraries and the GPLv2

[Florian Weimer]

* Lars Wirzenius:

> A compication in this is that even though the developers of a program
> would be happy with linking to OpenSSL, people who've written other
> libraries the program uses, or other code included in the program, may
> not be. I'm such a person. If some code I've released some code under
> GPL2 (only), and you link use it in a way that causes it to be linked
> with OpenSSL without asking me, you'll make me unhappy. I'm unlikely
> to sue you (life is too short), but I might grumble lengthily into my
> cup of tea.

This is interesting.

Do you hold the same position regarding newer versions of GCC (which
have changed the libgcc license to GPLv3+ (plus exceptions), which is
probably as GPLv2-compatible as the OpenSSL license)?

On some architectures, libgcc is required for full “long long”
support, so it's not really optional even for C.

Re: System libraries and the GPLv2

[Florian Weimer]

* Richard Fontana:

> On Thu, Mar 30, 2017 at 05:08:24AM +0200, Carlos Alberto Lopez Perez wrote:
>
>> Do you (or anyone else) _really_ think the copyright holders of the GPL
>> program in question had any intention ever of not allowing their program
>> to be used along with OpenSSL, when they where the ones implementing
>> support for using it on the first place?
>
> This, I would say, encapsulates the real Fedora/Red Hat position on
> this issue to the extent there is one. It assumes that the intent of
> the copyright holders can be determined from their actions.

But it's not clear that applies when at the time the software was
released by upstream, the libraries were GPLv2-compatible, and we
started linking against GPLv2-incompatible versions only later.  This
has already happened with readline (GPLv3 and later), and libgcc
(GPLv3 and later with GCC exception).  It was avoided for GMP, which
used to be LGPLv2+, briefly LGPLv3+, and finally GPLv2 or LGPLv3+.

You could argue that if upstream continues to make compatibility fixes
for later readline versions, or enable compiling with later GCC
versions, they give implied permission to link with those
GPLv2-incompatible library versions.  But I think this argument breaks
down, at least formally, when there are many copyright holders, and
not everyone contributes to the changes that enable this kind of
forward compatibility (first technically, and then implicitly
license-wise).  On the other hand, when a larger upstream project
granted us a linking exception for OpenSSL, they probably did not
obtain consent from all the copyright holders, either.

What really annoys me about this whole situation is this: I think no
one presently argues that the GPLv2 prevents people from distributing
pre-built binaries for proprietary operating systems.  I can take
Hotspot (a component of OpenJDK which is GPLv2-only), compile it with
Microsoft Visual Studio, and distribute the result.  But I suddenly
can't ship pre-built binaries, as a free software distribution,
because I happen to have upgraded the system compiler past GCC 4.2,
thus got the new GPLv3+ license for libgcc, and can't link GPLv2-only
Hotspot against that anymore.  This can't be right, can it?

Re: System libraries and the GPLv2

[Florian Weimer]

* Adam Borowski:

> The approach of commercial companies to both code and law is "it compiles? 
> Ship it!".  They have sizeable legal departments, so the question they ask
> themselves is not "is this legal?" but "are costs of possible litigation
> smaller or greater than the cost of doing it correctly?".  On the other
> hand, individuals who'd be sued in Debian's case (the SPI has no deep
> pockets thus is an unlikely target) have no legal clout so being fully in
> the clean is our only defense.

But we make similar risk assessments all the time.  Some of us even
strongly defend the right to anonymous contributions, that is, they
argue against keeping exact copyright records, which could otherwise
be used to identify the party who added code for which they did not
have permission (so that Debian or a liable Debian contributor could
recover their costs from them).

Re: System libraries and the GPLv2

[Florian Weimer]

* Josh Triplett:

> The intention of the system library exception is to allow third
> parties to ship Free Software on proprietary platforms, while
> pointedly *disallowing* the vendor of the proprietary platform from
> doing so.  As historical precedent, note that some vendors explicitly
> provided entirely separate media containing GNU applications, in order
> to satisfy that requirement.

But those vendors have since stopped doing that, and the GNU tools are
shipped along with the rest of the operating system (Solaris, Macos),
or at least together with the libc they are linked against (Interix).

Re: dlopen()ing shared libraries considered harmful (was Re: Depends/Recommends from libraries)

[Florian Weimer]

* Guillem Jover:

>> dlopen()ing dependencies in the way that is most commonly implemented,
>> with dlopen("libimobiledevice.so.6") and dlsym(handle, "idevice_new")
>> or similar, has some practical problems for Debian:
>> 
>> * The libraries used aren't visible to dpkg-shlibdeps. The maintainer has
>>   to know what dlopen() calls the code will make, and either hard-code an
>>   appropriate Depends (or in this case Recommends), or link a dummy
>>   executable against the same things that are dlopen()ed (as is done
>>   in packages like wine and openal-soft) and use that for dpkg-shlibdeps.
>>   Either way, they have to remember to update it for every new upstream
>>   release. This is the sort of tedious-but-subtle work that we automate
>>   because otherwise it will inevitably be incorrect after a few releases.
>> 
>> * The exact symbols used aren't visible to dpkg-shlibdeps. The maintainer
>>   has to hard-code a version number that has all the required symbols.
>>   Again, this is the sort of thing that we automate because it will
>>   inevitably go wrong if done manually.
>
> And:
>
>  * Because the shared library SONAME is hard-coded in both code and
>packaging metadata, whenever there's a transition with a SOVERSION
>bump that could have been handled with a simple mass binNMU, instead
>it requires manual intervention to patch those, while making sure it
>still works due to the points above.

And:

* For regular dynamic linking, the static linker (ld) puts the default
  symbol version seen in the linked DSO into the object which refers
  to that DSO, so that each symbol refers to a fixed symbol version.
  This symbol version matches the header file contents of the library
  at the time, and is consistent with the link.  With dlopen/dlsym,
  this step does not happen, and dlsym will pick the newest (*) symbol
  version.  This version might not match what was in the header files
  at compilation time.  (Theoretically, it would be possible to
  determine the applicable symbol version at compile time and use
  dlvsym, but no one does that.)

(*) Not quite because we have a bug:


>> The pedantically correct way to have weak library dependencies is this
>> multi-level chain of linking, analogous to what is documented for APIs
>> that wrap dlopen() such as libltdl and GLib's GModule:
>> 
>> - eventual API user, e.g. /usr/bin/gnome-software
>>   dlopen()s:
>> - a plugin intended to be dlopen()ed, e.g. 
>> libgs_plugin_flatpak-user.so
>>   has DT_NEEDED on:
>> - libflatpak0
>
> I don't think this is pedantical at all, it's IMO the only sane and
> correct way to handle this.

Right, this way also allows the static linker to do its job and fix
the symbol version.

System libraries and the GPLv2 (was: Re: GnuTLS in Debian)

[Florian Weimer]

* Andreas Metzler:

> Problems:
> -
> GnuTLS 2.12.x is dated. It is upstream's old-old-old stable release
> (followed by 3.[012].x). The latest bugfix release happened in
> February 2012, later security fixes have not been solved by releases but
> by patches in GIT. GnuTLS 2.12.x does not work with the recently released
> gcrypt 1.6.0. Therefore we will need keep another old library version
> around. (I doubt that GnuTLS upstream will port GnuTLS 2.12.x to newer
> gcrypt.)
>
> How to continue from here/solve this:
> -
> #1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian.
>
> #2 Fork GnuTLS 2 for Debian.
>
> #3 Hope that GMP is relicensed to GPL2+/LGPLv3+

(this is what eventually happened.

> #4 Hop nettle switches to a different arbitrary precision arithmetic 
> library.
>
> #5 Declare GMP to be a system library.
>
> #6 Move to GnuTLS3, drop GnuTLS2. Packages which cannot use GnuTLS3
> for license reasons will need to drop TLS support or be relicensed or
> be ported to a different TLS library.

(snip)

> #5 was how Fedora looked at the OpenSSL library issue. Since Debian
> has another viewpoint on OpenSSL I somehow doubt we would use it for
> GMP.

I would like to suggest to treat more libraries as eligible for the
system library exception within Debian.

This would apply to OpenSSL (pre- and post-relicensing), and, perhaps
more importantly, to libgcc (a widely used C run-time library which is
mandatory to link against on some architectures).

libgcc been available under the GPLv3 for some time, and yet we still
use it to compile GPLv2-only programs.  (My understanding is that the
GCC run-time library exception that applies to libgcc does not make
the library licensing GPLv2-compatible, it only helps licenses without
copyleft-like provisions.)

Would it be possible to get real legal advice on this matter, with the
concrete goal to find a usable process to leverage the system library
exception in the GPLv2?

Re: Graphical package installers & debconf

[Florian Weimer]

* Sean Whitton:

> On Thu, Mar 23, 2017 at 07:14:35AM -0400, Jeremy Bicha wrote:
>> It is also useless for someone who will install Chromium from the
>> Software app (gnome-software) included in 'gnome-core' since the
>> Software app does not display debconf prompts.
>
> Do you know if this is a missing feature or a deliberate choice?

Doesn't GNOME Software originate from the lands of RPM?  There is
nothing like Debconf in the RPM stack, and package installation
*always* has to be non-interactive.

Accepted quagga 1.0.20160315-3 (source amd64 all) into unstable

[Florian Weimer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 18 Oct 2016 22:06:18 +0200
Source: quagga
Binary: quagga quagga-dbg quagga-doc
Architecture: source amd64 all
Version: 1.0.20160315-3
Distribution: unstable
Urgency: high
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Florian Weimer <f...@deneb.enyo.de>
Description:
 quagga - BGP/OSPF/RIP routing daemon
 quagga-dbg - BGP/OSPF/RIP routing daemon (debug symbols)
 quagga-doc - documentation files for quagga
Closes: 841162
Changes:
 quagga (1.0.20160315-3) unstable; urgency=high
 .
   * Apply patch to fix CVE-2016-1245.  Closes: #841162.
Checksums-Sha1:
 8afff4e642bdbd52a885d81dc1cbfc133efe1f10 1850 quagga_1.0.20160315-3.dsc
 b259d7c52c491cf1e344cc4785d205c5aeb46522 36352 
quagga_1.0.20160315-3.debian.tar.xz
 ee3a2272b49a713cfca26efc3bc605f6801244d0 2121450 
quagga-dbg_1.0.20160315-3_amd64.deb
 71f4cdbc58a20412acc78afb0336b3bfa44864bb 977348 
quagga-doc_1.0.20160315-3_all.deb
 54c33120528d67f680a8ba6a896ff2ec8aba4128 1365952 
quagga_1.0.20160315-3_amd64.deb
Checksums-Sha256:
 2ac5563066e3f352078c8f9467f05eebf0fdd9e5e39afb0a327482cff8566f26 1850 
quagga_1.0.20160315-3.dsc
 f0e1051396f152e505a0cc9f4244bc44ffbecf11dd494b8e62d2f0da3dfa9be3 36352 
quagga_1.0.20160315-3.debian.tar.xz
 bbf95f62562b0e14a0e8acd7035763be7790c06046bce154678994a3d1d5682b 2121450 
quagga-dbg_1.0.20160315-3_amd64.deb
 7a05abf817663ff3229eba6632c043ab92c3078ad5179eb498b08b6b232ada78 977348 
quagga-doc_1.0.20160315-3_all.deb
 29fec831cc8074178833550b844bedccd5d29e5c0f72fa65cb4401b27342951b 1365952 
quagga_1.0.20160315-3_amd64.deb
Files:
 88ab56fa14f17513b6df3213d55a75ec 1850 net optional quagga_1.0.20160315-3.dsc
 5ac532674484640b6c7311e685e4cdbe 36352 net optional 
quagga_1.0.20160315-3.debian.tar.xz
 803c52c98443fa01460f7f8b79335533 2121450 debug extra 
quagga-dbg_1.0.20160315-3_amd64.deb
 aee71677f2c4ed27fc642c36be453749 977348 net optional 
quagga-doc_1.0.20160315-3_all.deb
 9411c17fc6a01be7bbb2f6d0f5e786c7 1365952 net optional 
quagga_1.0.20160315-3_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJYBo3UAAoJEL97/wQC1SS+bbEH/jor+NnM32r2OxJU3StcS/Yh
Y9twZSf3DTiKXe7a9YFPB2QgjrIdoDonPFLXu/kF5SiW3Jv0TJH3d7WHeQJqy0aK
rpBxJSGsHdpPhzFLi63pKgLoPRkVaAh8Yv8zxx8Ks1WsC/yhVU2zMIrDSwR5uuyf
6R6rx6kazjL7m7wRR+dwSmPP3ARhHBi0Ti/egxee6hwW9QFLxeR0d8UkAUufxbgt
ezaW2y95ydxxXg51WvpOEljnkuT/ef/G6Z03z6J6SKb85YRmm1+go8F+/PtaSzzw
UIr66wnj5RukZ8rUmmE9X/Ys1DlpmF9TO46qw+KwS4J6p3ZVhG+zSb01TBwP7kk=
=rCHJ
-END PGP SIGNATURE-

Re: New project goal: Get rid of Berkeley DB (post jessie)

[Florian Weimer]

* Adrien CLERC:

> Le 19/06/2014 11:38, Ondřej Surý a écrit :
>> List of affected maintainers follows:
>>
>> Loic Minier 
>>evolution-data-server (U)
>>rpm (U)

> I am just a simple user of rpm. Yes, I use rpm for inspecting,
> debugging, and so on. I don't use it for managing packages on my Debian
> box, but I guess that removing BerkeleyDB from rpm is not an option. If
> I'm wrong, I'll be glad to hear it :)

It's very hard to remove because rpm has functionality similar to
debootstrap.  The created RPM database in the chroot must be
compatible with older RPM versions (such as those in CentOS and Red
Hat Enterprise Linux).

Re: PIE and static libraries

[Florian Weimer]

* Jiri Jaburek:

> On 09/12/16 13:42, Jakub Wilk wrote:
>> * Bálint Réczey , 2016-09-12, 13:21:
 Reading up on the subject so far, I got the impression that most
 static libraries should be built with PIE, but not necessarily PIC
 (to allow building PIE(xecutable)s, but discourage creating shared
 libraries from those static ones.)
>> 
>> How does it discourage creating shlibs?
>> 
>> Also, is there a reliable way for a static checker (such as Lintian) to
>> distinguish between -fPIC and -fPIE static libraries?
>
> There is (kinda),
> https://sourceware.org/ml/libc-alpha/2015-03/msg00605.html

Yes, but we have moved on, and PIE has received optimizations since
then which reduce the cost on platforms with PC-relative loads and
stores.  These optimizations eliminate unneeded redirections, but also
make the resulting objects incompatible with full PIC mode.

Without PIC, ELF dynamic linking allocates global variables referenced
from the main program as if defined in the main program, and patches
all DSOs to reference those global variables.  This mechanism ensures
that the objects which go into the main executable do not need to
determine, at compile time, whether a variable reference ends up
resolving to a definition in a DSO or not.

Re: Debian is not welcome on Microsoft Azure

[Florian Weimer]

* Hideki Yamane:

>  So I thinks we should care such situations, and try to improve it
>  by adding hyperv-daemons package to stable (it means for production
>  system).

Sure.  The first step is to determine if we want to build this from
the kernel source package (as a new binary package), or if we want to
extract the sources and add a new source package to stable.  This has
to be coordinated with the kernel team, and someone who is familiar
with Hyper-V needs check if we can use the old tools from the jessie
kernel.

I don't see anyone on this thread who opposes to such a change in
principle, so it's just stuck until someone does the necessary work
(who also has access to the required infrastructure to test things).

Florian

Re: Minutes from the 32bit architectures in Debian-bof

[Florian Weimer]

* Andreas Barth:

 * Florian Weimer (f...@deneb.enyo.de) [150823 17:02]:
 * Andreas Barth:
 
  Specific issues:
  - for i386, there is still sold new hardware with 32bit-only. Are
there open issues for i386 (apart from the 32bit-generic ones)?
 
 FWIW, for x32, the security team would prefer if support in the Debian
 amd64 kernel would remain guarded by a boot-time option.

 You mean that on an kernel from an amd64-installation, 32bit binaries
 could only be used with an appropriate boot option?

Yes, x32 binaries.  This subarchitecture is different from i386.

Re: Minutes from the 32bit architectures in Debian-bof

[Florian Weimer]

* Andreas Barth:

 Specific issues:
 - for i386, there is still sold new hardware with 32bit-only. Are
   there open issues for i386 (apart from the 32bit-generic ones)?

FWIW, for x32, the security team would prefer if support in the Debian
amd64 kernel would remain guarded by a boot-time option.

Re: GitHub “pull request” is useful and can be easily integrated'’

[Florian Weimer]

* Ondřej Surý:

 Also it still doesn't solve the issue the quarrel here is about - you
 still need some account - in this case a local GitLab instance account
 (well, Alioth could be used if that's in LDAP) to contribute.

I don't quite understand this criticism.  Surely direct write access
to the repository always needs some sort of authentication step?

Git offers various ways to contribute to a repository without direct
write access.  For some high-profile projects, that's the only way to
contribute.

Maybe users of Git-something sites are more likely to reject
contributions over non-Git-something channels, but that's a social
issue and not really inherent to the services these sites provide.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87pp3oiijz@mid.deneb.enyo.de

Re: debian github organization ?

[Florian Weimer]

* Jérémy Lal:

 i was wondering if debian had a github account as an organization, where
 maintainers could be added.

Github has a single-account-per-person policy (unless you pay, I
think), so for those of us with multiple affiliations, it is difficult
to join a Debian organization on Github.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lheciif3@mid.deneb.enyo.de

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

[Florian Weimer]

* Andreas Metzler:

 It is just that an application may not link at the same time against
 libnettle4 and libgnutls-deb0-28 3.3.15-5.  Neither Debian nor afaik
 any other major distribution supports this kind of complexity in its
 dependency system (conditional dependencies).

And package dependencies are too coarse anyway because this is
something that happens on the ELF level.

In general, we do not add versioned dependencies to make sure that a
fixed version of a dependency affecting a package is installed allong
with the latter package.  I don't think this case (bug 784009) is all
that different.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d1zoihj9@mid.deneb.enyo.de

Re: GitHub “pull request” is useful and can be easily integrated'’

[Florian Weimer]

* Paul Wise:

 On Sun, Jul 19, 2015 at 5:49 PM, Florian Weimer wrote:

 I don't quite understand this criticism.  Surely direct write access
 to the repository always needs some sort of authentication step?

 Not sure about for http/https/ssh but the git protocol allows for
 anonymous push access and git-daemon supports that if you turn it on.
 On top of that you can layer some restrictions using hooks.

 https://ikiwiki.info/tips/untrusted_git_push/

Sure, and it's also possible to have shared accounts with well-known
passwords, see anonymous CVS.  But for write access, this is such a
fringe use case that I don't think this is what concerns people.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fv4kgzxr@mid.deneb.enyo.de

Re: debian github organization ?

[Florian Weimer]

* Andrew Shadura:

 On 19 July 2015 at 11:52, Florian Weimer f...@deneb.enyo.de wrote:
 i was wondering if debian had a github account as an organization, where
 maintainers could be added.

 Github has a single-account-per-person policy (unless you pay, I
 think), so for those of us with multiple affiliations, it is difficult
 to join a Debian organization on Github.

 That's not true, you can have organisations and teams.

Please read what I wrote.  The single account policy means that users
would have to share authentication information across different roles,
which may not be acceptable.

(You could argue that organization objecting to such sharing should
pay for an account for their users, though.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87si8kfkgs@mid.deneb.enyo.de

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Florian Weimer]

* Thomas Goirand:

 As a friend puts it:

 This is a fundamental problem/defect with xz. This (and a lot of other
 such defects, e.g. non-robustness of xz archives that easily lead to
 file corruption etc)

Corruption breaks signatures, making the file unusable, so that's not
really an issue for dpkg.

 are the reason that there is lzip (and which is why
 gnu.org has, on a technical basis, decided that lzip is official
 gzip-successor for gnu software releases when they come in tarballs).

The only GNU projects currently releasing .lz tarballs are gmp,
ddrescue, rcs, autoconf-archive, guile-sdl, ocrad, moe, gawk, ed,
gettext.  Several more projects have stopped providing .lz files, but
did so in the past.

Reading http://www.nongnu.org/lzip/lzip.html, I see no commitment
towards convergence.  In fact, the web page gives the impression that
further compression algorithms might be added in the future, breaking
your use case (“a much more elaborated way of finding coding sequences
of minimum size than the one currently used by lzip could be
developed”).


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87h9p0ihu0@mid.deneb.enyo.de

Re: The Spirit of Free Software, or The Reality

[Florian Weimer]

* Bas Wijnen:

 I disagree that the safebrowsing part is not serious, especially
 considering that it continues to send a message there on every new
 page you visit.

That's not what should happen.  Google can essentially make Iceweasel
do that by serving appropriate static data instructing the browser to
do so, but it should not happen in practice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4ich1wa@mid.deneb.enyo.de

Re: The Spirit of Free Software, or The Reality

[Florian Weimer]

* Paul Wise:

[Safe Browsing]

 Why doesn't it just download the full list and do checks client-side?

The contents of this list is proprietary.  Google might not even own
it (or parts of it).  There may also be a need for operational secrecy
for such technology.

Publishing the list would also increase liability for Google because
it is easier to spot third parties whose rights are violated.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zj2sh1wt@mid.deneb.enyo.de

Re: The Spirit of Free Software, or The Reality

[Florian Weimer]

* Bas Wijnen:

 I have some experience with safe browsing, but indeed I have not
 looked up how it works.  I do know that it continuously sends data
 to Google, and I have quite a bit of confidence in their capability
 and willingness to use that data for tracking.  From your
 description it sounds like that is not trivial, but there are smart
 people at Google, and they have near infinite resources.

One aspect that could be fixed fairly easily: Iceweasel sends your
Google cookies along those requests (and accepts new Google cookies if
you do not have them).  That's not really required by the protocol.

Similarly for OCSP requests: There should be no need at all to accept
or send cookies on them.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87twt0h1sw@mid.deneb.enyo.de

Re: The Spirit of Free Software, or The Reality

[Florian Weimer]

* Nikolaus Rath:

 On Jul 15 2015, Bas Wijnen wij...@debian.org wrote:
 As Jakub was saying: just starting it up without even visiting a site yet 
 will
 do a POST and a *few dozen* GET requests.  Shouldn't it be waiting with its
 checks until it actually knows what to check?  What is it sending them at
 browser startup?

 Why don't you check the code?

I found the Mozilla safe-browsing code *very* hard to read.  It's not
just the protocol, you also need to know a lot about how Javascript is
used as part of the browser implementation.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87pp3oh1qs@mid.deneb.enyo.de

Re: debian github organization ?

[Florian Weimer]

* Ben Caradoc-Davies:

 On 19/07/15 21:52, Florian Weimer wrote:
 * Jérémy Lal:
 i was wondering if debian had a github account as an organization, where
 maintainers could be added.
 Github has a single-account-per-person policy (unless you pay, I
 think), so for those of us with multiple affiliations, it is difficult
 to join a Debian organization on Github.

 GitHub organizations are free for open source, and each GitHub user
 can be a member of multiple unrelated organizations:
 https://github.com/blog/674-introducing-organizations

I am aware of that, and it's not what I'm concerned about.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878uacgzuv@mid.deneb.enyo.de

Re: Replacement Default Icons for Iceweasel [was Re: The Spirit of Free Software, or The Reality]

[Florian Weimer]

* Don Armstrong:

 On Thu, 16 Jul 2015, Don Armstrong wrote:
 This is why I said if they're necessary, then they're necessary.

 Here's a set of default icons which can trivially be expanded to avoid
 shipping those icons and downloading them: 

 for icon in ebay google wikipedia bing; do 
 convert -size 16x16 xc:white -pointsize 8 \
 -font 'DejaVu-Sans' -fill black \
 -stroke none \
 -draw text 0,7 '${icon:0:3}' \
 -draw text 0,14 '${icon:3:3}' \
 ${icon}.png;
 done;

Thanks, I think that's an acceptable interim solution until we can
obtain permission to ship the actual logos under terms we like.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zj2sfku5@mid.deneb.enyo.de

Re: linking perl statically against libperl

[Florian Weimer]

* Niko Tyni:

 If there are several /usr/bin/perl processes and /usr/bin/perl is
 statically linked against libperl, every process has its own copy of
 the libperl code in memory. In the case of dynamic linking, there's just
 one copy.

No, there is still only one copy in memory (or two if applications are
running which use the embedded interpreter).

In fact, static linking needs less non-sharable per-process data
because tables for dynamic relocations are not needed.  The savings
are perhaps not as pronounced for the Perl interpreter because it is
linked with --export-dynamic (or equivalent) to export symbols to Perl
XS modules.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3qfwtt1@mid.deneb.enyo.de

Re: Debian PHP upgrade

[Florian Weimer]

* Andile Ntebe:

 On 2015/03/28, 10:42 PM, Florian Weimer f...@deneb.enyo.de wrote:

* Andile Ntebe:

 Im not sure why Gareth said PHP, I’m referring to Apache 2.2.22.

 The below vulnerabilities seem to affect this version:

Hi Andile,

Where did you get this list?

 Here you go:

 http://httpd.apache.org/security/vulnerabilities_22.html

Okay, as others have already told you, this list does not apply to the
Apache httpd packages as shipped by Debian because the relevant fixes
have been applied.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87iodhuyis@mid.deneb.enyo.de

Re: Debian PHP upgrade

[Florian Weimer]

* Andile Ntebe:

 Im not sure why Gareth said PHP, I’m referring to Apache 2.2.22.

 The below vulnerabilities seem to affect this version:

Hi Andile,

Where did you get this list?

Thanks,
Florian


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87384odfbq@mid.deneb.enyo.de

Accepted debsecan 0.4.18 (source all) into unstable

[Florian Weimer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sun, 22 Feb 2015 20:09:52 +0100
Source: debsecan
Binary: debsecan
Architecture: source all
Version: 0.4.18
Distribution: unstable
Urgency: low
Maintainer: Florian Weimer f...@deneb.enyo.de
Changed-By: Florian Weimer f...@deneb.enyo.de
Description:
 debsecan   - Debian Security Analyzer
Closes: 749421 761344 778798
Changes:
 debsecan (0.4.18) unstable; urgency=low
 .
   * Increase compatibility with Python 2.6 in squeeze.  The
 ssl.wrap_socket function does not take a ciphers argument.
   * Add dependency on ca-certificates
   * Use https:// URLs everywhere.  Closes: #749421
   * Add Vcs-Git heheader.  Closes: #761344
   * Move primary repository to Gitorious.  Closes: #778798
Checksums-Sha1:
 fef2252e5626dd7bff62c5f601f5758d03d8f352 1131 debsecan_0.4.18.dsc
 8405a9eb6be8b380c412f5ed9770f0daff3fbdb9 565912 debsecan_0.4.18.tar.gz
 1c2457b6a5a70076ebe4b32c51334400abe2ecc9 36432 debsecan_0.4.18_all.deb
Checksums-Sha256:
 5345b239ba9bf0103ee253b85bdf5a78ea284cfdc6cec0fd65c9f52e0362be9d 1131 
debsecan_0.4.18.dsc
 b8ab3226511ff213b057a8515a6eecbf9d5e8ee31479e1303b45049650199dcd 565912 
debsecan_0.4.18.tar.gz
 8b1dc106df7da8b9407222f15d1c3eaa8fd7707d393f9038ec30706be2aaa08b 36432 
debsecan_0.4.18_all.deb
Files:
 51e30cb75c18a27e728c50c4415639d6 1131 admin optional debsecan_0.4.18.dsc
 993bdce273283dc86279c7df11faf3a5 565912 admin optional debsecan_0.4.18.tar.gz
 04d62fc7cbbf012ffab3408bc7f857d8 36432 admin optional debsecan_0.4.18_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJU6jUDAAoJEL97/wQC1SS+30QH/0PzG/BWREJ8UZt9f1PFElU1
Z+sC854jjr/W6tbW+oymphNw4dA7GtjkVYNTh2Iz8KqL/xgAB1cPwRYH2JAlA0Lk
Hk6X+V9ojU3CKC/e+KAWVt2g8cnZyWjZXrWD5inw4Hx/AnI6qLRmm/5WT6od/fze
G8H44DkB7NEja/1UjOKJA6D06N+/WWkO0FA+L8S4veW6/GSbQD3nyPApZXQk5Vwf
s839TwKbkzQNKGQ/b5GCA4lBXro7pVprn4v5tuPEZyzqWuANXSlYFrJy8BxC3WpL
eoj0C75d88oPZbLYQhtNzwDDDbYa1YFi5Gsh2J1+cR4su3qEE0Gb7E9h8KCaBgE=
=WHB8
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ypchu-0006zn...@franck.debian.org

Re: Architectures where unaligned access is (not) OK?

[Florian Weimer]

* Simon McVittie:

 - OK: any-i386, any-amd64

SSE2 is part of amd64 and i386, and has strict alignment requirements.
This is why stack alignment bugs in the toolchain are usually fatal.
(We still support SSE2-less i386 installations, I think, but some
libraries will use SSE2 when available.)

i386 also supports alignment checking.  It used to be possible to run
quite a bit of code with that flag switched on, but nowadays, glibc
string functions use unaligned accesses in some cases because on
current implementations, they are faster than the alternatives, so
this way of debugging alignment issues no longer works.

 - not OK: armel

Many architectures take a significant performance hit.  Usually, this
is because unaligned accesses are emulated in a kernel trap (which can
be switched off to debug these performance issues, hence the
differences in system behavior).

Some older i386/amd64 implementations have relatively costly unaligned
access, too, but only in the order of a couple of cycles, not the
hundreds or thousands kernel emulation will require.

It is very difficult to write correct C code which uses unaligned
pointers because they are an aliasing violtion as well.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k32mfl41@mid.deneb.enyo.de

Accepted doscan 0.3.3-1 (source amd64) into unstable

[Florian Weimer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 25 Oct 2014 15:52:02 +0200
Source: doscan
Binary: doscan
Architecture: source amd64
Version: 0.3.3-1
Distribution: unstable
Urgency: low
Maintainer: Florian Weimer f...@deneb.enyo.de
Changed-By: Florian Weimer f...@deneb.enyo.de
Description:
 doscan - port scanner for discovering services on large networks
Changes:
 doscan (0.3.3-1) unstable; urgency=low
 .
   * New upstream version
   * Use autotools_dev
Checksums-Sha1:
 2e4844e9d7efcde628588142eb704ae1bd2520fe 1320 doscan_0.3.3-1.dsc
 a8765fd2209600d9d291cfcaecd2883955ec2f12 133457 doscan_0.3.3.orig.tar.gz
 27f5c4b7d5f1a15fad2df9584e4f32ae26cfd630 1693 doscan_0.3.3-1.diff.gz
 4d32ab95eef40f154c680b117578f85913d7b30f 45864 doscan_0.3.3-1_amd64.deb
Checksums-Sha256:
 29ab807a068df22e7494fc9db644beaa08050b4bfd1a02f5be9489c52a26c6e8 1320 
doscan_0.3.3-1.dsc
 ae8f1f0669ff8cb168914dc5a855e4c132a272d82d4161d3b146af04e47a686f 133457 
doscan_0.3.3.orig.tar.gz
 7a832e2c45e8df06f7c81fef892bcfdf28bb9b3320feaa9e907979c4df4e13eb 1693 
doscan_0.3.3-1.diff.gz
 3d19e22477a2b6e99aea14759c20d95876e1141785efb32832a295762f149834 45864 
doscan_0.3.3-1_amd64.deb
Files:
 afeb4f4b70049f0b5583afda02545c19 1320 net optional doscan_0.3.3-1.dsc
 e955d0c194c9b9be17464cfaa35de4e2 133457 net optional doscan_0.3.3.orig.tar.gz
 ffe43659708dbbc16a7c914053d949da 1693 net optional doscan_0.3.3-1.diff.gz
 1bfbd9e9dae2e12654cdf33d17a1eafa 45864 net optional doscan_0.3.3-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJUS7iAAAoJEL97/wQC1SS+EMIH/iDapSkmK3BNUhCSMsRTQq+Z
IDbf0MMg3Z4ltHAvaBpMnEIG4EXIXRc25UH47k0bQImsn+jQ+SYwduIzNRLlzmAG
JJ8oZAAqxg92nPuOej2HCd/WVzaZQ7DcLGzZYNlHsR/uDn5Qn5NKlngKYeEmjbVG
XMF+T6x6sgulyrnkZEPTxgJZxPan44Yw6jD1lNtX/C/oBFxQir8Nfb+sVBuGNz3b
9LVYmBnYI8Hck6HPbB7x15fbUjVwXOAdO+SbYkMhl2oaYpq/SPhU+6VdTE+L0ycD
nd8JmEib/NaEhkv0DwYthOXMmRI3IDdLDC7DitNkz60JBiZlEPhdhuP6JYZqBGg=
=6qwU
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xi3ms-0006ej...@franck.debian.org

Re: GPL-3 openssl: provide a -nossl variant for a library

[Florian Weimer]

* Henrique de Moraes Holschuh:

 The problem is that Debian is the operating system distributing the system
 libraries, and that all packages Debian distributes are *also* part of that
 same operating system.

 https://lists.debian.org/debian-legal/2002/10/msg00113.html
 https://people.gnome.org/~markmc/openssl-and-the-gpl.html

 And read this, especially slides 8, 9, and 10:
 www.lawseminars.com/materials/08OPSMA/opsma%20m%20fontana%2010-29%20new%20up.pdf

 Where it is clear it is indeed a concern.  Note that Fontana is both a
 lawyer, and co-author of the GPLv3.

But Fedora, whose policies Richard Fontana helped to shape over the
years, considers OpenSSL to be a library covered by the system library
exception.

In practice, the FSF seems to agree with this interpretation (for the
GPLv2) because Microsoft Services for UNIX links GPL software such as
GCC against a proprietary libc which is part of the same software
package, and I don't think the FSF has even tried to stop them.  (This
libc is BSD-derived and not the Windows kernel or something like that,
it is an intermediate layer.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fvef9pdu@mid.deneb.enyo.de

Accepted doscan 0.3.2-1 (source amd64) into unstable

[Florian Weimer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 23 Oct 2014 07:34:22 +0200
Source: doscan
Binary: doscan
Architecture: source amd64
Version: 0.3.2-1
Distribution: unstable
Urgency: low
Maintainer: Florian Weimer f...@deneb.enyo.de
Changed-By: Florian Weimer f...@deneb.enyo.de
Description:
 doscan - port scanner for discovering services on large networks
Changes:
 doscan (0.3.2-1) unstable; urgency=low
 .
   * New upstream version
   * Use current debhelper, but keep dh-autoreconf
Checksums-Sha1:
 aefb75d0fba281e3f6e18dad07b8e7adad91e66d 1320 doscan_0.3.2-1.dsc
 da731a96c2db1ec12fd967a3443127f84a462376 131997 doscan_0.3.2.orig.tar.gz
 aa4f05d3c43816760606454e40a1214d30a7051e 1664 doscan_0.3.2-1.diff.gz
 4b523541d71bd038e83249f20f2c5be4e6303bb5 45812 doscan_0.3.2-1_amd64.deb
Checksums-Sha256:
 750a284da1ba71f64fc5813b3b9ba181f06eef7495cc30d031105db2e825d210 1320 
doscan_0.3.2-1.dsc
 38c74a2f672dae59e6de85e7bd5c6daa5bc1dcb4ed332e58913b115538436136 131997 
doscan_0.3.2.orig.tar.gz
 2d68f4d281e52e40c1ffa370b9389fa267001326ab939890456b1985788fadbf 1664 
doscan_0.3.2-1.diff.gz
 d49a171d8e191e9ce0eefadfa765b6430bbd6ea553e1b188b93283ff254394be 45812 
doscan_0.3.2-1_amd64.deb
Files:
 9760009b862ac4f89f595e37932cf424 1320 net optional doscan_0.3.2-1.dsc
 69e3f56fe06769db9b4b4c07fed74830 131997 net optional doscan_0.3.2.orig.tar.gz
 5111f3527b2201d194fae11beb4d8a24 1664 net optional doscan_0.3.2-1.diff.gz
 91783708a8061a3f90ae939b978a5825 45812 net optional doscan_0.3.2-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJUSJ1yAAoJEL97/wQC1SS+d4MH/RtvQQ5DLqKLG91ApRUthqFd
vgkwof0EYxY3gw8zNlJdypTZlcoTUPPW/Q7gW4pfQyuHm2qwZOadK7CltOCpTnqz
Yy9XwM89p5whCMwXdAte59l77IhNB1qaOmfZkEZqqRO2TsfqZVp4uQdA5CS/LIhy
Gm9JcjcqSY7YmvfuTK4PtHsXERAMFFmmfmubMlDdf5hz0wlL8iTLuGjfBHe02awO
6/JIV7HN6G5AsPkiPcEebYzC4gG6hxl7VlOfnAwMzSUo8EscfjIosfJLRKuOGvf2
gDHfBafyVUKyGwMfH/5lQ2VGm80yZHJsVClbSE8FYb1CsLwS6r6pjGGeOpjueC0=
=ADDG
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xhbur-0008t8...@franck.debian.org

Re: GPL-3 openssl: provide a -nossl variant for a library

[Florian Weimer]

* Michael Fladischer:

 Considering this, is it a good idea to provide a librabbitmq1-nossl
 binary package that was built without OpenSSL while still having
 librabbitmq1 with OpenSSL-support?

We do not do this for Python, which links against OpenSSL, and which
is used from software under the GPL, so I don't really see why we have
to do this for other infrastructure components.

The long term solution is to rely on the system library exception to
regain GPL compatibility, just as Fedora does.  It's really
unavoidable with libraries moving to (L)GPLv3 and the presence of
GPLv2-only software in Debian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k33snzxn@mid.deneb.enyo.de

Automating snapshot.debian.org downloads

[Florian Weimer]

I'm reconstructing the history of a package in Debian (with the
eventual goal of putting it into a Git repository).

Are there any existing clients that help with automated downloads of
multiple .dsc/source package bundles from snapshot.debian.org? I don't
want to reinvent this particular wheel.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a94ol0q3@mid.deneb.enyo.de

Re: Automating snapshot.debian.org downloads

[Florian Weimer]

* ChangZhuo Chen (陳昌倬):

 On Wed, Oct 22, 2014 at 02:59:00PM +0200, Florian Weimer wrote:
 Are there any existing clients that help with automated downloads of
 multiple .dsc/source package bundles from snapshot.debian.org? I don't
 want to reinvent this particular wheel.

 Try the following command:

 git-import-dscs --debsnap package

Thanks, this is quite helpful.  It even picks up the change authors
and dates.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lho8jlg6@mid.deneb.enyo.de

Bug#765512: general: distrust old crypto algos and protocols perdefault

[Florian Weimer]

* Christoph Anton Mitterer:

 Not sure if there is already some concentrated effort, but I think
 there should be one, i.e.:

Fedora is currently working on this:

  https://fedoraproject.org/wiki/Changes/CryptoPolicy

However, it is an ongoing effort to make applications adhere to the
system defaults.  (In the past, cryptographic libraries had bad
defaults, so policy had to be put into application code.  Yuck.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjcxawmf@mid.deneb.enyo.de