Re: Debian Project Leader Elections 2020: Candidates 3 / 5

[Geert Stappers]

On Sun, Mar 15, 2020 at 01:08:35AM +0100, Kurt Roeckx - Debian Project 
Secretary wrote:
> We're now into the campaigning period. We have 5 candidates this year:

five

> - Jonathan Carter
> - Sruthi Chandran
> - Brian Gupta
> 

three


That doesn't add up.
Please retransmit.


Regards
Geert Stappers
-- 
Silence is hard to parse

ITP: golang-software.sslmate-src-go-pkcs12 -- Go library for encoding and decoding PKCS#12 files

[James Tocknell]

Package: wnpp
Severity: wishlist
Owner: James Tocknell 

* Package name: golang-software.sslmate-src-go-pkcs12
  Version : 0.0~git20190322.6e380ad-1
  Upstream Author : SSLMate
* URL : https://github.com/SSLMate/go-pkcs12
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go library for encoding and decoding PKCS#12 files

 package pkcs12 GoDoc
 (https://godoc.org/software.sslmate.com/src/go-pkcs12) import
 "software.sslmate.com/src/go-pkcs12"
 .
 Package pkcs12 implements some of PKCS#12 (also known as P12 or PFX).
 It is intended for decoding P12/PFX files for use with the crypto/tls
 package, and for encoding P12/PFX files for use by legacy applications
 which do not support newer formats.  Since PKCS#12 uses weak encryption
 primitives, it SHOULD NOT be used for new applications.
 .
 This package is forked from golang.org/x/crypto/pkcs12, which is frozen.
 The implementation is distilled from https://tools.ietf.org/html/rfc7292
 and referenced documents.
 .
 This repository holds supplementary Go cryptography libraries.
 Import Path Note that although the source code and issue tracker
 for this package are hosted on GitHub, the import path is:
 software.sslmate.com/src/go-pkcs12
 .
 Please be sure to use this path when you go get and import this package.
 Download/Install The easiest way to install is to run go get -u
 software.sslmate.com/src/go-pkcs12. You can also manually git clone
 the repository to $GOPATH/src/software.sslmate.com/src/go-pkcs12.
 Report Issues / Send Patches Open an issue or PR at
 https://github.com/SSLMate/go-pkcs12


This is needed for https://github.com/FiloSottile/mkcert

ITP: mkcert -- A simple zero-config tool to make locally trusted development certificates with any names you'd like.

[James Tocknell]

Package: wnpp
Severity: wishlist
Owner: James Tocknell 

* Package name: mkcert
  Version : 1.4.1-1
  Upstream Author : Filippo Valsorda
* URL : https://github.com/FiloSottile/mkcert
* License : BSD-3-clause
  Programming Lang: Go
  Description : A simple zero-config tool to make locally trusted
development certificates with any names you'd like.

 mkcert mkcert is a simple tool for making locally-trusted development
 certificates. It requires no configuration.
 .
 ``` $ mkcert -install Created a new local CA at
 "/Users/filippo/Library/Application Support/mkcert" 💥 The local CA
 is now installed in the system trust store! ⚡️ The local CA is now
 installed in the Firefox trust store (requires browser restart)! 🦊
 .
 $ mkcert example.com "*.example.com" example.test localhost 127.0.0.1 ::1
 Using the local CA at "/Users/filippo/Library/Application Support/mkcert"
 ✨
 .
 Created a new certificate valid for the following names 📜
  - "example.com" - "*.example.com" - "example.test" - "localhost" -
  "127.0.0.1" - "::1"
 .
 The certificate is at "./example.com+5.pem"
 and the key at "./example.com+5-key.pem" ✅ ``` https://user-images.githubusercontent.com/1225294/51066373-96d4aa80-15be-11e9-91e2-f4e44a3a4458.png
">
 Using certificates from real certificate authorities (CAs) for development
 can be dangerous or impossible (for hosts like example.test, localhost
 or 127.0.0.1), but self-signed certificates cause trust errors. Managing
 your own CA is the best solution, but usually involves arcane commands,
 specialized knowledge and manual steps.
 .
 mkcert automatically creates and installs a local CA in the system
 root store, and generates locally-trusted certificates. mkcert does
 not automatically configure servers to use the certificates, though,
 that's up to you.  Installation Warning: the rootCA-key.pem file that
 mkcert automatically generates gives complete power to intercept secure
 requests from your machine. Do not share it.  macOS On macOS, use Homebrew
 (https://brew.sh/)
 .
 .
 brew install mkcert brew install nss # if you use Firefox
 .
 .
 or MacPorts (https://www.macports.org/).
 .
 .
 sudo port selfupdate sudo port install mkcert sudo port install nss #
 if you use Firefox
 .
 Linux On Linux, first install certutil.
 .
 .
 sudo apt install libnss3-tools
 -or-
 sudo yum install nss-tools
 -or-
 sudo pacman -S nss
 -or-
 sudo zypper install mozilla-nss-tools
 .
 .
 Then you can install using Linuxbrew (http://linuxbrew.sh/)
 .
 .
 brew install mkcert
 .
 .
 or build from source (requires Go 1.13+)
 .
 .
 git clone https://github.com/FiloSottile/mkcert && cd mkcert go build
 -ldflags "-X main.Version=$(git describe --tags)"
 .
 .
 or use the pre-built binaries
 (https://github.com/FiloSottile/mkcert/releases).
 .
 For Arch Linux users, mkcert
 (https://www.archlinux.org/packages/community/x86_64/mkcert/) is available
 on the official Arch Linux repository.
 .
 .
 sudo pacman -Syu mkcert
 .
 Windows On Windows, use Chocolatey (https://chocolatey.org)
 .
 .
 choco install mkcert
 .
 .
 or use Scoop
 .
 .
 scoop bucket add extras scoop install mkcert
 .
 .
 or build from source (requires Go 1.10+), or use the pre-built binaries
 (https://github.com/FiloSottile/mkcert/releases).
 .
 If you're running into permission problems try running mkcert as an
 Administrator.  Supported root stores mkcert supports the following root
 stores: • macOS system store• Windows system store• Linux variants
 that provide either • update-ca-trust (Fedora, RHEL, CentOS) or•
 update-ca-certificates (Ubuntu, Debian, OpenSUSE, SLES) or• trust
 (Arch)• Firefox (macOS and Linux only)• Chrome and Chromium•
 Java (when JAVA_HOME is set) To only install the local root CA into
 a subset of them, you can set the TRUST_STORES environment variable
 to a comma-separated list. Options are: "system", "java" and "nss"
 (includes Firefox).  Advanced topicsAdvanced options ```
 -cert-file FILE, -key-file FILE, -p12-file FILE
 Customize the output paths.
 -client
 Generate a certificate for client authentication.
 .
 -ecdsa
 Generate a certificate with an ECDSA key.
 .
 -pkcs12
 Generate a ".p12" PKCS #12 file, also know as a ".pfx" file,
 containing certificate and key for legacy applications.
 .
 -csr CSR
 Generate a certificate based on the supplied CSR. Conflicts with
 all other flags and arguments except -install and -cert-file.
 .
 ```
 .
 Note: You must place these options before the domain names list.  Example
 .
 mkcert -key-file key.pem -cert-file cert.pem example.com *.example.com
 .
 S/MIME mkcert automatically generates an S/MIME certificate if one of
 the supplied names is an email address.
 .
 .
 mkcert fili...@example.com
 .
 Mobile devices For the certificates to be trusted on mobile devices,
 you will have to install the root CA. It's the rootCA.pem file in the
 folder printed by mkcert -CAROOT.
 .
 On iOS, you can either use AirDrop, ema

Re: Is distro-tracker accessible by some sort of API?

[Jelmer Vernooij]

On Sat, Jan 18, 2020 at 01:50:29AM +1100, Stuart Prescott wrote:
> > does source package 'foo' exist in release 'bar'?
> > 
> > Looking at the UDD wiki page and the associated examples, it seems like
> > the query I need is something roughly like:
> > 
> > SELECT COUNT(*) FROM public.packages WHERE source='foo' AND release='bar';
> > 
> > Is this the best approach?
> 
> FWIW there are python bindings and CLI tools for UDD floating around ... I 
> really should package them (and having people interested in them would be 
> good motivation for that)

+1

Having the python bindings for UDD packaged would be great.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Re: FTP Team -- call for volunteers

[Michael Lustfield]

On Sun, 15 Mar 2020 05:10:21 +0100
Adam Borowski  wrote:

> On Sat, Mar 14, 2020 at 08:04:01PM -0400, Scott Kitterman wrote:
> > On Saturday, March 14, 2020 6:37:46 PM EDT Martin wrote:  
> > > On 2020-03-14 13:37, Sean Whitton wrote:  
> > > > (packages in NEW must not be downloaded from ftp-master.d.o to your
> > > > local machine)  
> > > Just curious: Why is that the case?  
> > Out of an abundance of caution.  Until after the package has been reviewed, 
> > there's no knowing if it's distributable and downloading a package from ftp-
> > master.d.o to another machine outside debian.org is a distrubution.  
> [...]
> This "abundance of caution" rule is utterly obsolete this millenium.  It
> made some sense when distributing software was done by snail-mailing a
> floppy or a stack of them.

My knee-jerk response is to agree. There is a lock which also applies to
reviewing a package. This means only one person can be looking at it at a time.
We often just open a github/gitlab/etc. page if multiple people need to discuss
the package (usually team member asking a trainee something). The content has
already been distributed. Why should this be any different from mentors.d.n,
where such practice is required?

The problem is that this server is *the* distribution point for the Debian
archive. This feels like a weird gray area that shouldn't be messed around with.

Personally, I was shocked when I found out we do review on the same server that
hosts the archive. I would have expected a separate server for review. However,
my expectation comes from younger environments, where CD/CI and extensive code
review processes are expected. When I try to picture how the current system
evolved (more evident as you dig into dak source...), it makes sense.

Making a new server to push reviews to would remove that gray area, since it
would effectively be identical to mentors.d.n; especially considering how
easily one could upload to ftp-master instead of mentors... (guilty)

Something like this would take a pretty deep dive into dak, and a new server,
and all the goodies that would go along with such a transition.

Unfortunately, from my view, such a change would be nearly impossible. I can't
even get documentation fixes merged into dak or even reviewed. I don't imagine
such a large change would ever get accepted.


If we could even just do something like an DNA, saying we will definitely
destroy everything we download, we'd at least be able to write our own review
tools. :/

+1 (Re: FTP Team -- call for volunteers)

[Holger Levsen]

On Sun, Mar 15, 2020 at 06:55:43AM -0500, Michael Lustfield wrote:
> > > > > (packages in NEW must not be downloaded from ftp-master.d.o to 
> > > > > your
> > > > > local machine)  
> > > > Just curious: Why is that the case?  
> > > Out of an abundance of caution.  Until after the package has been 
> > > reviewed, 
> > > there's no knowing if it's distributable and downloading a package from 
> > > ftp-
> > > master.d.o to another machine outside debian.org is a distrubution.  
> > [...]
> > This "abundance of caution" rule is utterly obsolete this millenium.  It
> > made some sense when distributing software was done by snail-mailing a
> > floppy or a stack of them.
> 
> My knee-jerk response is to agree. There is a lock which also applies to
> reviewing a package. This means only one person can be looking at it at a 
> time.
> We often just open a github/gitlab/etc. page if multiple people need to 
> discuss
> the package (usually team member asking a trainee something). The content has
> already been distributed. Why should this be any different from mentors.d.n,
> where such practice is required?
> 
> The problem is that this server is *the* distribution point for the Debian
> archive. This feels like a weird gray area that shouldn't be messed around 
> with.
> 
> Personally, I was shocked when I found out we do review on the same server 
> that
> hosts the archive. I would have expected a separate server for review. 

+1, though talk is cheap :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: FTP Team -- call for volunteers

[Simon Richter]

Hi,

On 15.03.20 12:55, Michael Lustfield wrote:

> Personally, I was shocked when I found out we do review on the same server 
> that
> hosts the archive. I would have expected a separate server for review. 
> However,
> my expectation comes from younger environments, where CD/CI and extensive code
> review processes are expected. When I try to picture how the current system
> evolved (more evident as you dig into dak source...), it makes sense.

There are two aspects to distribution: a license from the copyright
holders, and export permissions from the country where the archive is
hosted.

Both of these are *currently* rather relaxed in the US, with DMCA safe
harbor provisions and a blanket permission to export cryptography (the
existence of which Debian had a large hand in), which allows places like
Github to operate.

It is unclear how much the DMCA protects us if we have a review process
before publication (i.e. are we still good if we have any manual step,
or must publication be fully automated?), and there is also a bill
underway that would tighten requirements on cryptography software again
if not defeated.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Seeking sponsor for new package

[Aaron Boxer]

On Sat, Mar 14, 2020 at 7:45 PM Emmanuel Arias  wrote:

> Hi!,
>
> Great I can see. I've not my tools with me (I am on vacation) but, I will
> be happy
>  to review on a week the package.
>

Thank You !




On Fri, Mar 13, 2020 at 7:24 PM Aaron Boxer  wrote:
>
>> Thanks, Emmanuel. Following the git-buildpackage page, I have created
>> three new branches
>> on my repo: debian-branch, upstream-branch and pristine-tar. The debian
>> folder can be found
>> in those three branches.
>>
>> And thanks for the link, I will take a look.
>>
>> Cheers,
>> Aaron
>>
>>
>>
>> On Fri, Mar 13, 2020 at 10:32 AM Emmanuel Arias <
>> emmanuelaria...@gmail.com> wrote:
>>
>>> Hi  Aaron,
>>>
>>> Thanks for contribute to Debian. I would like to force the Fabrice.
>>> Try to use git-buldpackage and read
>>> https://www.debian.org/doc/manuals/maint-guide/
>>>
>>> e.g. on master branch I can't see the debian folder. If you have the
>>> three recommended branch:
>>> * deban/master
>>> * upstream (in your case master ¿?)
>>> * pristine-tar
>>>
>>> will be more easy to review.
>>>
>>>
>>>
>>> Cheers,
>>> Arias Emmanuel
>>> @eamanu
>>> http://eamanu.com
>>>
>>> El jue., 12 de mar. de 2020 a la(s) 19:23, Aaron Boxer
>>> (boxe...@gmail.com) escribió:
>>> >
>>> > Hello!
>>> > As you may have seen, I am interested in packaging my image compression
>>> > library for debian:
>>> >
>>> > https://github.com/GrokImageCompression/grok
>>> >
>>> > I've tested the packaging locally and as far as I can tell, it's all
>>> working correctly.
>>> > The only thing missing now is a properly updated copyright file.
>>> >
>>> > Would anyone here be interested in helping get this package submitted ?
>>> >
>>> > Thanks!
>>> > Aaron
>>>
>>

Bug#953992: ITP: python-flit -- simple way to put Python packages and modules on PyPI

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: flit
  Version : 2.2.0
  Upstream Author : Thomas Kluyver 
* URL : https://github.com/takluyver/flit
* License : BSD 3-clause license
  Programming Lang: Python
  Description : simple way to put Python packages and modules on PyPI

Flit is a simple way to put Python packages and modules on PyPI. It tries to
require less thought about packaging and help you avoid common mistakes.
.
Flit supports PEP 517 Python packaging.
.
Make the easy things easy and the hard things possible is an old motto from
the Perl community. Flit is entirely focused on the easy things part of that,
and leaves the hard things up to other tools.
.
Specifically, the easy things are pure Python packages with no build steps
(neither compiling C code, nor bundling Javascript, etc.). The vast majority
of packages on PyPI are like this: plain Python code, with maybe some static
data files like icons included.

I intend to maintain this in PAPT (Python Applications Packaging Team).

PEP 517 style packages are becoming more common and while flit does
generate a setup.py file for non-PEP 517 build system use, it is not
particularly satisfying.  I'm motivated to package this after having had
to patch such a package to make it build complete metadata.  Debian will
be better off if we can use the upstream tools.

Upstream provides a good discussion of why flit in addition to other
Python oriented build tools:

https://flit.readthedocs.io/en/latest/rationale.html

Flit does use flit to build, but it includes a bootstrap script so it
can build itself without in archive bootstrapping.

using salsa as a package triage system? "channels"?

[Steffen Möller]

Hello,

I am mostly a the periphery of Debian for Debian Med, but at times this
makes me add build dependencies that are of interest for everyone. Like,
basic packages for nim. :o) Whenever we go out to the world we keep
stressing that Debian Med is not separate from Debian at all. It is just
the name of a community. With today's  unbearable load for the FTP
masters maybe we have to reconsider - after all, the FTP masters only
see a fraction of what we really need in the distribution to solve
today's biological challenges.

If we had another kind of repository for Debian Med, then quite a bunch
of packages would not require the immediate scrutiny of our FTP masters.
Frankly, most of our users will just accept that some upstream developer
in github decided their software to be free and redistributable and
don't look much deeper - they have a biological problem to solve and
that package is part of a workflow that is today's best practice they
want to follow. This pragmatic stance has been taken by conda and while
our scrutiny is much accepted and praised in the scientific community,
our packaging falls behind in both scientific coverage and adoption rate.

The packaging of conda is not completely different from what Debian is
doing, but conda is much more community-driven. Since conda started wit
github, they basically had a salsa.d.o from day one. And they use it
much to its full potential: automated updates, community peer reviews,
very fast integration of new software. Two years ago we had first
developers halting their contribution to Debian since from a
biology-driven perspective, they cannot afford that extra effort since
the advent of conda. Conda folks suggest that Debian should concentrate
on the basic OS. And they have a point, especially since Conda gets
increasingly close to what Debian is offering, e.g. with respect to CI.

We cannot immediately adopt how conda is doing it since we would lose
what makes us special. But we can learn and could imho fairly easily
rewire Debian's package flow to make being an FTP master fun again. And
at the same time speed up the periphery. Suggestions:

 * the periphery gets their own repositories - happily also called
"channel" in analogy to conda
 * maintainer decides on what packages are auto-update-able within the
channel by routine-updates (referencing a script by )
 * channel-community upvotes the integration of packages with Debian
proper as a suggestion for FTPmasters
 * popcon gives feedback on the adoption of packages
 * FTPmasters pick new packages from the periphery channels as they see fit

I am not sure about the granularity of these channels. Maybe every blend
should have one or two channels. Obvious (to me) candidates:

 * med
 * astro
 * science
 * r
 * machine learning
 * 

To increase security especially when embracing new contributors without
sponsors, I am tempted to say that we should not keep the sources in the
git repository but analogously also to OpenWrt only maintain the debian
folder. I find this to work amazingly well.

We had discussed PPAs in the past - this suggestion is admittedly
similar. The interaction with salsa and ftpmasters is what renders it
most different, I tend to think. It is not an issue only of Debian Med -
the packages are too much interconnected, I think. The packages that
have most reverse dependencies to packages of many channels are the ones
that the FTPmasters may want to prioritize.

Steffen

Re: using salsa as a package triage system? "channels"?

[Mo Zhou]

Hi Steffen,

I still don't quite understand the proposed idea. Is it something like
the Debian version of Gentoo overlay?  My suggestion is that you should
make this proposal more specific, e.g.  by shedding some light on the
way of implementing it.

Unlike the other distros, as you must have noticed, the human cost per
package for debian is significantly higher than that for other distros
-- an Archlinux developer may update thousands of packages a day, but
for me (Debian) 10 packages per day is already lots of work.

That means third-party package channels will inherit the same cost per
package, even if such cost can be reduced by doing something unelegant.
In this direction I proposed DUPR in the past and provided an unelegant
demonstration implementation.

We also have some similar historical proposals, such as the Debian PPA
as you said, and the bikeshed (I don't know who named it but please
rename it for good wish).

On Sun, Mar 15, 2020 at 04:22:47PM +0100, Steffen Möller wrote:
> masters maybe we have to reconsider - after all, the FTP masters only
> see a fraction of what we really need in the distribution to solve
> today's biological challenges.

Sometimes you can tell FTP masters the important things via the
"Comments:" field in d/copyright as long as appropriate. FTP masters
and trainees won't skip this field.
 
> want to follow. This pragmatic stance has been taken by conda and while
> our scrutiny is much accepted and praised in the scientific community,
> our packaging falls behind in both scientific coverage and adoption rate.

Traditional packaging is lagging behind, or cannot even satisfy the user
demand. But that's exactly why business companies like anaconda exists.
As discussed before, I think we such a traditional distribution cannot
easily solve the problems that anaconda is trying to solve.
 
> Conda folks suggest that Debian should concentrate
> on the basic OS. And they have a point, especially since Conda gets
> increasingly close to what Debian is offering, e.g. with respect to CI.

I fully agree with conda folks that Debian should concentrate on the
basic OS, providing a solid base system for whoever the end user is.

Although one could have much fun working on low-popcon packages, but
the fact that "there won't be too many end users" is already
demotivating enough from time to time.

> We cannot immediately adopt how conda is doing it since we would lose
> what makes us special. But we can learn and could imho fairly easily
> rewire Debian's package flow to make being an FTP master fun again. And
> at the same time speed up the periphery. Suggestions:
> 
>  * the periphery gets their own repositories - happily also called
> "channel" in analogy to conda
>  * maintainer decides on what packages are auto-update-able within the
> channel by routine-updates (referencing a script by )
>  * channel-community upvotes the integration of packages with Debian
> proper as a suggestion for FTPmasters
>  * popcon gives feedback on the adoption of packages
>  * FTPmasters pick new packages from the periphery channels as they see fit

This part looks obscure to me. Could you provide more specific details?
 
> I am not sure about the granularity of these channels. Maybe every blend
> should have one or two channels. Obvious (to me) candidates:
> 
>  * med
>  * astro
>  * science
>  * r
>  * machine learning
>  * 

This indeed sounds like Gentoo overlay. I like gentoo overlay.
I also fancy gentoo features that Debian doesn't have.
 
> We had discussed PPAs in the past - this suggestion is admittedly
> similar. The interaction with salsa and ftpmasters is what renders it
> most different, I tend to think. It is not an issue only of Debian Med -
> the packages are too much interconnected, I think. The packages that
> have most reverse dependencies to packages of many channels are the ones
> that the FTPmasters may want to prioritize.

Such priority value can be calculated, say, by counting the number of
reverse dependencies. Someone interested in this could try to implement
this feature in dak and the FTP team will see this hint and tell the
priorities.

Re: using salsa as a package triage system? "channels"?

[Simon McVittie]

On Sun, 15 Mar 2020 at 16:22:47 +0100, Steffen Möller wrote:
> To increase security especially when embracing new contributors without
> sponsors, I am tempted to say that we should not keep the sources in the
> git repository but analogously also to OpenWrt only maintain the debian
> folder.

Sorry, I'm not seeing how this increases security?

The Debian packaging for a package is completely trusted: any attack that
can be performed by an attacker with access to the upstream source code
can be done by an attacker with access to only the Debian packaging,
and there are additional attacks that can (in general) only be done by
attackers with access to the Debian packaging.

smcv

Re: FTP Team -- call for volunteers

[Theodore Y. Ts'o]

On Sun, Mar 15, 2020 at 01:53:44PM +0100, Simon Richter wrote:
> 
> > Personally, I was shocked when I found out we do review on the same server 
> > that
> > hosts the archive. I would have expected a separate server for review. 
> > However,
> > my expectation comes from younger environments, where CD/CI and extensive 
> > code
> > review processes are expected. When I try to picture how the current system
> > evolved (more evident as you dig into dak source...), it makes sense.
> 
> There are two aspects to distribution: a license from the copyright
> holders, and export permissions from the country where the archive is
> hosted.
> 
> Both of these are *currently* rather relaxed in the US, with DMCA safe
> harbor provisions and a blanket permission to export cryptography (the
> existence of which Debian had a large hand in), which allows places like
> Github to operate.
> 
> It is unclear how much the DMCA protects us if we have a review process
> before publication (i.e. are we still good if we have any manual step,
> or must publication be fully automated?), and there is also a bill
> underway that would tighten requirements on cryptography software again
> if not defeated.

Personally I think this worry that a private copying from
ftp-master.debian.org constitutes a legal risk is really way
overblown.  However, if we want to assume this highly paranoid
reading, one thing we could do is have an *optional* way where someone
who is uploading a package which is going to end up in the ftp-master
tar pit^H^H^H^H^H^H^H queue can pass a URL where ftp master assistants
can download the various artifacts to their own local laptop.
Sha256sum can be used to make sure what has been uploaded to debian
matches what has been downloaded from the sideload URL.

That way, *Debian* is not distributing, but the uploader is
distributing from their server.  So the legal risk (if any) isn't on
Debian.

The bigger thing which we might be able to do is to require minimal
review if the source package is already in the distribution, but the
main reason why it is in the ftp-master tar pit is because upstream
has bumped the major version number of a shared library, and so there
is a new binary package triggering what appears to be de novo review
by the ftp master team.  I understand there is a super-abundance of
caution which seems to drive all ftp-master team decisions, but
perhaps this could be eased, in the interests of reduce a wait time
of, in some cases greater than a year?

- Ted

Re: FTP Team -- call for volunteers

[Salvo Tomaselli]

If you think about it, even if you connect with ssh and use vim or
whatever remotely, the content of the files are reaching your screen,
so are being distributed anyway. Might as well just download them no?

Il giorno dom 15 mar 2020 alle ore 18:25 Theodore Y. Ts'o
 ha scritto:
>
> On Sun, Mar 15, 2020 at 01:53:44PM +0100, Simon Richter wrote:
> >
> > > Personally, I was shocked when I found out we do review on the same 
> > > server that
> > > hosts the archive. I would have expected a separate server for review. 
> > > However,
> > > my expectation comes from younger environments, where CD/CI and extensive 
> > > code
> > > review processes are expected. When I try to picture how the current 
> > > system
> > > evolved (more evident as you dig into dak source...), it makes sense.
> >
> > There are two aspects to distribution: a license from the copyright
> > holders, and export permissions from the country where the archive is
> > hosted.
> >
> > Both of these are *currently* rather relaxed in the US, with DMCA safe
> > harbor provisions and a blanket permission to export cryptography (the
> > existence of which Debian had a large hand in), which allows places like
> > Github to operate.
> >
> > It is unclear how much the DMCA protects us if we have a review process
> > before publication (i.e. are we still good if we have any manual step,
> > or must publication be fully automated?), and there is also a bill
> > underway that would tighten requirements on cryptography software again
> > if not defeated.
>
> Personally I think this worry that a private copying from
> ftp-master.debian.org constitutes a legal risk is really way
> overblown.  However, if we want to assume this highly paranoid
> reading, one thing we could do is have an *optional* way where someone
> who is uploading a package which is going to end up in the ftp-master
> tar pit^H^H^H^H^H^H^H queue can pass a URL where ftp master assistants
> can download the various artifacts to their own local laptop.
> Sha256sum can be used to make sure what has been uploaded to debian
> matches what has been downloaded from the sideload URL.
>
> That way, *Debian* is not distributing, but the uploader is
> distributing from their server.  So the legal risk (if any) isn't on
> Debian.
>
> The bigger thing which we might be able to do is to require minimal
> review if the source package is already in the distribution, but the
> main reason why it is in the ftp-master tar pit is because upstream
> has bumped the major version number of a shared library, and so there
> is a new binary package triggering what appears to be de novo review
> by the ftp master team.  I understand there is a super-abundance of
> caution which seems to drive all ftp-master team decisions, but
> perhaps this could be eased, in the interests of reduce a wait time
> of, in some cases greater than a year?
>
> - Ted
>


-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Re: FTP Team -- call for volunteers

[Alexis Murzeau]

Le 15/03/2020 à 19:59, Salvo Tomaselli a écrit :
> If you think about it, even if you connect with ssh and use vim or
> whatever remotely, the content of the files are reaching your screen,
> so are being distributed anyway. Might as well just download them no?
> 
I'm not a lawyer, but I'm thinking of this:

If it's just about legal risk, couldn't the responsibility of the right to 
redistribute of the uploaded software be moved on the uploader instead ?
So the uploader takes the responsibility of any redistribution of the uploaded 
software by Debian itself, the same way if he would have uploaded it to a 
social media are whatever.

That way, the legal responsibility burden is distributed on many peoples 
instead of a small number.
If one is not sure that the software is distributable, he can mail the upstream 
maintainers for a clue.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Re: FTP Team -- call for volunteers

[Neil McGovern]

On Sun, Mar 15, 2020 at 08:13:37PM +0100, Alexis Murzeau wrote:
> If it's just about legal risk, couldn't the responsibility of the
> right to redistribute of the uploaded software be moved on the
> uploader instead ?
> So the uploader takes the responsibility of any redistribution of the
> uploaded software by Debian itself, the same way if he would have
> uploaded it to a social media are whatever.
> 
> That way, the legal responsibility burden is distributed on many
> peoples instead of a small number.  If one is not sure that the
> software is distributable, he can mail the upstream maintainers for a
> clue.
> 

I am also not a lawyer, but have consulted with lawyers over similar
questions. This doesn't mean that Debian should consider this legal
advice, as Debian's situation is different than the one I have asked
about.

In theory, yes - this would move the liability to the uploader. However,
there are two issues with this:
1) The liability now rests with the uploader. This isn't something that
has really been done before, and we'd need to make sure that we're
comfortable with this.
2) We would be very limited in what checks we could actually do on new
packages. If we look too closely at packages, we stop being a
distributor, and start being a publisher. I'm not sure that we want to
move towards just being a distribution platform, rather than actually
doing QA checks.

Neil
-- 


signature.asc
Description: PGP signature

Re: FTP Team -- call for volunteers

[Philipp Kern]

On 2020-03-15 18:25, Theodore Y. Ts'o wrote:

The bigger thing which we might be able to do is to require minimal
review if the source package is already in the distribution, but the
main reason why it is in the ftp-master tar pit is because upstream
has bumped the major version number of a shared library, and so there
is a new binary package triggering what appears to be de novo review
by the ftp master team.  I understand there is a super-abundance of
caution which seems to drive all ftp-master team decisions, but
perhaps this could be eased, in the interests of reduce a wait time
of, in some cases greater than a year?


It also drives technical decisions. A much cleaner way from a deployment 
perspective would be to version kernel packages (and another pet peeve, 
nvidia packages) for every upload. That way updates and rollbacks can be 
managed more cleanly. (E.g. old kernel remaining in the boot menu, just 
like Ubuntu bumps with every upload these days.)


Now we could also fix that using a whitelist approach. But I have not 
seen much openness to tackling this part of NEW review and I am unsure 
why. From the public NEW tooling (I don't know dak's side) it pretty 
clearly does not look like a de novo review, as the diff to the archive 
is highlighted. Maybe another way would be to split the queue using a 
weighting function. But I am not aware of public documentation on how 
the review process is organized currently. Is there any?


(I'm happy to look at potential whitelisting code, but I think last time 
someone tried a big refactoring and introduction of tests was required 
of them prior to the contribution - which is a high bar after getting 
dak to run properly for development purposes first.)


Kind regards
Philipp Kern

Re: FTP Team -- call for volunteers

[Philip Hands]

Alexis Murzeau  writes:

...
> If it's just about legal risk, couldn't the responsibility of the
> right to redistribute of the uploaded software be moved on the
> uploader instead ?

How well does that work if someone outside the USA uploads software to
this USA based server which is legal in their own jurisdiction, but
falls foul of US law either by being on the server, or perhaps by being
distributed or (re)exported, say.

ISTR that uploading the ssh binaries from the UK seemed likely to
involve me crossing one or other of those lines back in the days of the
non-US archive (what with the RSA patent, and the export restrictions on
crypto at the time).

I know times have changed, but are we not still notionally informing
someone of every package that goes through NEW?  Telling them (perhaps
in a queued email that doesn't get sent any more) that each and every
package in Debian may well include crypto at some future date, if it
doesn't already, and declaring an initial point of distribution.

I would suspect that we might want to check that technical changes to
this process remain compatible with the paperwork, because the paperwork
may well be harder to change than the technology, and keeping the
paperwork in good working order may be a useful shield if some
capricious maniac ever managed to be in charge of things.

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#954028: ITP: node-babel7 -- compiler for next generation JavaScript

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: node-babel7
  Version : 7.4.5
  Upstream Author : Sebastian McKenzie 
* URL : https://babeljs.io/
* License : Expat
  Programming Lang: JavaScript
  Description : compiler for next generation JavaScript

Debian currently has a node-babel version 6. Version 7 is really
different and can cohabit with node-babel=6 (I already add an
alternative for /usr/bin/babeljs in node-babel 6).

I'd like to build a distinct node-babel7 since:
 * transition from node-babel 6 to node-babel 7 will be long
 * the 2 can cohabit: no common files (except alternative
   /usr/bin/babeljs)

Cheers,
Xavier

Re: FTP Team -- call for volunteers

[Alexandre Viau]

On Sat, Mar 14, 2020 at 4:38 PM Sean Whitton  wrote:
>
> Hello everyone,
>
> The FTP Team is seeking volunteers to train to become FTP Assistants.

Hello Sean,

I'd like to volunteer.

I remember answering to a call for volunteers in 2018. I was told that
I would be contacted for the next steps and it never happened. I hope
this time is different!

Thank you for taking the time to help bring in new blood to this team.

Cheers,

--
Alexandre Viau
av...@debian.org

Bug#954035: ITP: qtfeedback-opensource-src -- Qt Feedback module

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: qtfeedback-opensource-src
  Version : 5.0~git20180329.a14bd0bb-1
  Upstream Author : Chris Adams 
* URL : https://code.qt.io/qt/qtsystems.git
* License : LGPL-2.1 (with exception) or GPL-3
  Programming Lang: C++
  Description : Qt Feedback module

 Qt is a cross-platform C++ application framework. Qt's primary feature
 is its rich set of widgets that provide standard GUI functionality.
 .
 This package contains Qt Feedback module.
 .
 This Qt module will be packaged under the umbrella of the Debian Qt/KDE
 Maintainers and will be maintained by the Debian UBports Team.

Re: FTP Team -- call for volunteers

[Paul Wise]

On Sun, Mar 15, 2020 at 10:02 PM Philip Hands wrote:

> I know times have changed, but are we not still notionally informing
> someone of every package that goes through NEW?  Telling them (perhaps
> in a queued email that doesn't get sent any more) that each and every
> package in Debian may well include crypto at some future date, if it
> doesn't already, and declaring an initial point of distribution.

IIRC, the US government got bored of receiving mails for every upload
to Debian and requested that we stop the notifications.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: FTP Team -- call for volunteers

[Ismael Martinez]

Hello Sean.
I want to be a volunteer.
Please give me next steps.

Kind regards

Obtener Outlook para Android


De: Alexandre Viau 
Enviado: domingo, 15 de marzo de 2020 21:24
Para: spwhit...@spwhitton.name
Cc: debian-devel-annou...@lists.debian.org
Asunto: Re: FTP Team -- call for volunteers

On Sat, Mar 14, 2020 at 4:38 PM Sean Whitton  wrote:
>
> Hello everyone,
>
> The FTP Team is seeking volunteers to train to become FTP Assistants.

Hello Sean,

I'd like to volunteer.

I remember answering to a call for volunteers in 2018. I was told that
I would be contacted for the next steps and it never happened. I hope
this time is different!

Thank you for taking the time to help bring in new blood to this team.

Cheers,

--
Alexandre Viau
av...@debian.org

Re: FTP Team -- call for volunteers

[Sean Whitton]

Hello,

On Sun 15 Mar 2020 at 10:48PM +01, Philipp Kern wrote:

> Now we could also fix that using a whitelist approach. But I have not
> seen much openness to tackling this part of NEW review and I am unsure
> why. From the public NEW tooling (I don't know dak's side) it pretty
> clearly does not look like a de novo review, as the diff to the archive
> is highlighted. Maybe another way would be to split the queue using a
> weighting function.

Not sure what diff you have in mind, aside from the fact that
https://ftp-master.debian.org/new.html does indicate whether it's
source-NEW or binary-NEW.

On the other side you just get a whole source package and a list of
which files in the .changes are NEW.

> But I am not aware of public documentation on how the review process
> is organized currently. Is there any?

Yes: https://salsa.debian.org/ftp-team/manpages

For the mc extensions mentioned there, you can see my dotfiles:

https://git.spwhitton.name/dotfiles/tree/.config/mc?h=fasolo

https://git.spwhitton.name/dotfiles/tree/.local/share/mc/extfs.d?h=fasolo

-- 
Sean Whitton


signature.asc
Description: PGP signature