Bug#920424: ITP: python-flor -- efficient Bloom filter library

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-flor
  Version : 1.1.1
  Upstream Author : Andreas Dewes 
* URL : https://github.com/DCSO/flor/
* License : BSD_3-clause
  Programming Lang: Python
  Description : efficient Bloom filter library

Flor implements a Bloom filter class. A Bloom filter has a capacity (n) and a
false positive probability (p) that gives the probability that a filter filled
to capacity (i.e. with (n) distinct values inserted) will return True for an
element that is not in the filter.

I do plan to maintain this package as part of the DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlxK41ARHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wpa0AgAhpMIxNG3TaCj28HWnSYFaO6abJnzGzfm
FV6QXnSxAql/+roFYP2D8VpZx5UfJt/Kn+GTtflYDNO//Cjfr5Xi+iLPzhVwLV4n
a4TIXL8VHqel4oiFj3D7ejf7Iwx3RmisAD9pWgXr4+CJ/P5JVNP1tpQo3w66nzeq
41Hod83h6PROYLUHDDXPpycpiEOw8WJDn5iKt7IQ7vyyoq/bJYjCqJ3eL5UREWt1
y1c1IXYdpWDIL6drotDTavc8YAvC95iv28HVgpjH+VfVQr1yj6sI/Fw5YZed4wjg
tke+1bYjHvO672Y4x9UB/b/A9+vKYC98yylOVldrYh7XoP2GdJ9f6Q==
=BJLr
-END PGP SIGNATURE-

Re: Potentially insecure Perl scripts

[Dominic Hargreaves]

On Thu, Jan 24, 2019 at 08:00:12PM +, Holger Levsen wrote:
> On Thu, Jan 24, 2019 at 03:18:40PM +, Ian Jackson wrote:
> > To the Debian Perl maintainers: [...]
> > To the Debian security team: [...]
> 
> I've read the whole thread and am surprised "talking to upstream" (and
> fixing the issue there as well) hasn't really been on the table. :/ Did I
> miss that?

No, I don't think you did; thank you for putting it so succinctly.
As is obvious from the discussion, this is clearly not something which
can "just" be fixed in a security upload, since any meaningful change
will break a lot of scripts which rely on it. It's also far too big
a change of behaviour to be patching in Debian without involving upstream,
and would need to be staged in unstable first.

By comparison, the work preparing patches and then analysing
the fallout for the '.' in @INC removal (which mostly happened under
embargo), took about a year between the more serious apt related
security impact being understood by the perl5 security team and public
disclosure[1]. And that was with a lot of effort from different quarters.

Some have postulated that the breakage caused here is likely to be
at least as bad. I don't have a clear assessment of that yet but
this discussion is ongoing.

I have informally made a few upstream perl folks aware of this
thread, but I have not raised it formally as a bug until I have had a
chance to understand the various issues a bit better. But I think I
can safely say that this isn't something that's going to appear in
stable-security any time soon.

It does seem like the upstream plan from 2008 to introduce <<>> and
then get scripts updated to be safer didn't work, as many people writing
perl was not aware of this new operator. So there is definitely scope for
reconsidering upstream - but again, this won't happen overnight.

Also, I think it's worth trying to identify what the worst extent
of the issue is. Whilst I don't agree with some who say that this isn't
a security issue at all, I don't know of any real-world cases where
it would be exploitable for remote code execution. If someone would
like to contradict me, please feel free to mail off-list. Either way,
the fact remains that if untrusted/unsanitised input is being passed
into your @ARGV, then something is already wrong. It is worth
noting that it took a real (embarged) RCE exploit to get the wheels in
motion to eventually fix '.' in @INC.

Thanks,
Dominic.
on behalf of the Debian perl maintainers

[1] 

Bug#920435: ITP: mender-cli -- A general-purpose CLI for the Mender backend

[Andreas Henriksson]

Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson 

* Package name: mender-cli
  Version : 1.1.0-1
  Upstream Author : Mender
* URL : https://github.com/mendersoftware/mender-cli
* License : Apache-2.0
  Programming Lang: Go
  Description : A general-purpose CLI for the Mender backend

 Mender is an open source over-the-air (OTA) software updater
 for embedded Linux devices. Mender comprises a client running at the
 embedded device, as well as a server that manages deployments across
 many devices.
 .
 This package contains a standalone tool that makes it
 much easier to work with the Mender server management APIs
 (https://docs.mender.io/apis/management-apis).
 .
 The goal with mender-cli is to simplify integration between the Mender
 server and cloud services like continuous integration (CI)/build
 automation.

Bug#920437: ITP: displaylink -- Proprietary driver for DisplayLink devices

[Hanno Stock]

Package: wnpp
Severity: wishlist
Owner: Hanno Stock 

* Package name: displaylink
  Version : 4.4
  Upstream Author : DisplayLink (UK) Ltd.
* URL : https://www.displaylink.com/downloads
* License : proprietary
  Programming Lang: binary
  Description : Proprietary driver for DisplayLink devices

This is the proprietary binary component of the driver for DisplayLink
devices. It communicates via libusb with the DisplayLink device and uses
the opensource evdi kernel module for presenting a virtual graphics
device to the system.

-

DisplayLink devices are for example USB based docking stations and
USB-attachable secondary screens. Unfortunately newer DisplayLink devices
are not supported by libdlo, an open source driver for older DisplayLink
devices. 

However DisplayLink provides an Ubuntu installer for their newer drivers
and allows repackaging the binary components for other distributions.
According to a DisplayLink employee: "The text of the license was written
to ensure the driver can be repacked by other distros and redistribute.
As long as the text of license file is replicated, and binaries are
redistributed as provided in the .run package (unmodified), and it is
still possible to identify what component is what and where it came from,
the license terms are met IMO." [1]

In order for Debian to support DisplayLink devices it would make sense
to package this driver for the non-free component.

[1] https://www.displaylink.org/forum/showthread.php?t=64854&highlight=license

Re: Potentially insecure Perl scripts

[Ian Jackson]

Vincent Lefevre writes ("Re: Potentially insecure Perl scripts"):
> I fear that this is not that simple: I suppose that this will break
> scripts that modify @ARGV to make <> secure. :(

The easiest way to sanitise a string to make it safe for 2-argument
open involves:
 * prepending ./ if the string does not start with /
 * appending \0 (a nul byte)
The result is also a valid operand for 3-argument open.

Now some people may have prepended < needlessly but (i) if you thought
about this problem this hard you would probably try to make your thing
compatible with a hypothetical fixed <> (ii) we're probably in a small
minority of a tiny minority here (iii) changing the workaround so it
works for both is easy.

So I think this was a reasonable question to ask, but the answer is
that this is very unlikely to be a significant problem.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#920443: ITP: salmid -- rapid Kmer based Salmonella identifier from sequence data

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: salmid
  Version : 0.1.23
  Upstream Author : Henk den Bakker
* URL : https://github.com/hcdenbakker/SalmID
* License : MIT
  Programming Lang: Python
  Description : rapid Kmer based Salmonella identifier from sequence data
 SalmID enables rapid confirmation of Salmonella spp. and subspp. from
 sequence data.  This is done by checking taxonomic ID of single isolate
 samples.  Currently only IDs Salmonella species and subspecies, and
 some common contaminants (Listeria, Escherichia).

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/salmid

Bug#920449: ITP: gnucap-custom -- gnucap-custom provides a basis for customisation of the GNU circuit analysis package

[Felix Salfelder]

Package: wnpp
Severity: wishlist
Owner: Felix Salfelder 

* Package name: gnucap-custom
  Version : 0.0.1
  Upstream Author : Felix Salfelder 
* URL : https://gitlab.com/gnucap/gnucap-custom
* License : GPLv3+
  Programming Lang: C++
  Description : A basis for Gnucap customisation

Gnucap-custom provides a customisable executable for Gnucap, the GNU
circuit analysis package. It includes plugins improving readline
support, input processing, module loading and some tweaks. The package
provides the makefiles and loader used by gnucap-adms, which aids
compiling behavioural models.

I intend to maintain the package inside the pkg-electronics packageing
team.

Re: Potentially insecure Perl scripts

[Ian Jackson]

Holger Levsen writes ("Re: Potentially insecure Perl scripts"):
> On Thu, Jan 24, 2019 at 03:18:40PM +, Ian Jackson wrote:
> > To the Debian Perl maintainers: [...]
> > To the Debian security team: [...]
> 
> I've read the whole thread and am surprised "talking to upstream" (and
> fixing the issue there as well) hasn't really been on the table. :/ Did I
> miss that?

This bug was reported upstream here 18 years ago
  https://rt.perl.org/Public/Bug/Display.html?id=2783
and they took of those years to sort-of half-document it.

I guess you mean that we should try again ?  That's probably
worthwhile.

Maybe it would be best if this were fronted by someone who can bring
themselves to be more diplomatic about this situation than I can find
it in myself to be right now.


In the meantime we do need to bear in mind that we do have
approximately these two options:

 1. Change the behaviour of perl so that it matches the majority of
the documentation, so that -n and -p and <> fulfil their purpose
and can be used, and so that they satisfy the expections (or at
least wishes) of the vast majority of Perl programmers.

Risk a probably tiny amount of fallout.

If we do this in Debian without cooperation from upstream, set an
example which might lead other distros to fix it too; albeit
through diverging from upstream behaviour.

 2. Internally in Debian file a massive MBF to review thousands
and thousands of uses for safety.

Leave the world's existing scripts to be insecure and tolerate
that people will continue to write insecure scripts.

Write clumsy circumlocutions everywhere instead of <> and -p and
-n.  (Note that <<>> is not right because it does not honour `-'.)

Add notes to the documentation saying never to use <> or
-p or -n (WTF).

(2) certainly cannot be done quickly.  If (1) cannot be done quickly
it should IMO be done slowly.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Potentially insecure Perl scripts

[Ian Jackson]

Sorry for not reading the whole thread first, so my last mail didn't
take account of this one...

Dominic Hargreaves writes ("Re: Potentially insecure Perl scripts"):
> No, I don't think you did; thank you for putting it so succinctly.
> As is obvious from the discussion, this is clearly not something which
> can "just" be fixed in a security upload, since any meaningful change
> will break a lot of scripts which rely on it.

I don't think that changing this will break any appreciable number of
scripts.

> By comparison, the work preparing patches and then analysing the
> fallout for the '.' in @INC removal (which mostly happened under
> embargo), took about a year between the more serious apt related
> security impact being understood by the perl5 security team and
> public disclosure[1]. And that was with a lot of effort from
> different quarters.

I think the @INC problem was clearly much harder than this.  That much
stuff broke was unsurprising.

> Some have postulated that the breakage caused here is likely to be
> at least as bad. I don't have a clear assessment of that yet but
> this discussion is ongoing.

AFAIAA so far no-one has presented even one example of an actual
published program which would stop working if we made this change.

> Also, I think it's worth trying to identify what the worst extent
> of the issue is. Whilst I don't agree with some who say that this isn't
> a security issue at all, I don't know of any real-world cases where
> it would be exploitable for remote code execution. If someone would
> like to contradict me, please feel free to mail off-list.

Example of how this could be used for remote code execution:

1. Someone sends you a tarball of some files.
2. You extract the tarball.
3. You do
  program ./*
   for any program which uses while(<>).

There are probably programs that do the equivalent of this
programmetically, but finding them will be almost impossible, because
the <> bug means that, for example, /usr/bin/fixcvsdiff, has a
security hole if run on untrusted filenames.

So to find whether there are easy exploits it will be necessary to
search for programs which run fixcvsdiff.  And then inspect them all
to see if they always use trustworthy filenames.  And do that for all
hundreds or thousands of values of fixcvsdiff.

> Either way,
> the fact remains that if untrusted/unsanitised input is being passed
> into your @ARGV, then something is already wrong. It is worth
> noting that it took a real (embarged) RCE exploit to get the wheels in
> motion to eventually fix '.' in @INC.

Maybe we should not wait for that this time ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.