Bug#932259: ITP: psl.js -- JavaScript domain name parser based on the Public Suffix Lisl

2019-07-16 Thread Xavier Guimard
Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: psl.js
  Version : 1.2.0
  Upstream Author : Lupo Montero 
* URL : https://github.com/lupomontero/psl
* License : Expat
  Programming Lang: JavaScript
  Description : JavaScript domain name parser based on the Public Suffix 
Lisl

The Public Suffix List is a cross-vendor initiative to provide an accurate
list of domain name suffixes.

The Public Suffix List is an initiative of the Mozilla Project, but is
maintained as a community resource. It is available for use in any
software, but was originally created to meet the needs of browser
manufacturers.

psl.js is the JavaScript implementation, tested against the test data
hosted by Mozilla.

psl.js will provide node-psl (needed to update node-tough-cookie) and
libjs-psl. It will be maintained under pkg-js team umbrella.



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

2019-07-16 Thread Vincent Tondellier
On Tuesday 16 July 2019 23:11:24 Florian Weimer wrote:
> * 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

...

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

They do very different things.

Let me try a short description :
newuidmap - set the uid mapping of a user namespace (from manpage)
fuidshift - shift the uid/gid of files *on disk*

fuidshift is basically a recursive
chown $(( $(stat -c '%u' "$path") + $uidshift )) "$path"

It does not use or configure user namespaces or containers.

It's useful for the creation of containers images, for example when the 
container root filesystem is read-only (squashfs) and the container engine 
can't change the uids at runtime (see for example systemd-nspawn --private-
users=pick / --private-users-chown).

So fuidshift may be used to prepare a directory for later use by newuidmap, 
but that's about it.

> 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: git & Debian packaging sprint report

2019-07-16 Thread Scott Kitterman



On July 16, 2019 3:37:04 PM UTC, Russ Allbery  wrote:
>Scott Kitterman  writes:
>
>> Except that we have different requirements than git.  Git isn't
>looking
>> for security properties from SHA-1, so it's highly likely it'll meet
>> their accident avoidance requirements long after it's no longer
>> appropriate for security related assertions.
>
>> I don't think adding more SHA-1 in a security sensitive context is a
>> good plan.
>
>I talked this over briefly in the security pod at work with some other
>security engineers who know more crypto than I do to sanity-check my
>initial opinion.
>
>The consensus among all of us was that if you have an opportunity to
>pick
>something other than SHA-1 when designing a new protocol, you should. 
>But
>if it's not simple to pick a different hash, SHA-1 preimage resistance
>is
>reasonable and the other design properties of the system should
>dominate
>any concern about SHA-1 preimage attacks.  If the system is vulnerable
>to
>collisions, that's another matter; there are viable SHA-1 collisions. 
>But
>given the design described, I don't think it is.  (That said, designing
>the system for hash agility if possible is certainly recommended.)

Thank you for researching this.  I'm less discomfited about SHA-1 in the 
short-term now.  I still don't think that in the long run assuming Git will 
solve algorithm agility is the right answer since we do have different 
requirements.

For now, I think it's enough to be able to describe the path that could be 
followed if we conclude we need to move forward to something new before Git.  I 
think the actuality of it seems far enough off that there's no need to actually 
implement an alternative algorithm now.

Scott K



Re: default firewall utility changes for Debian 11 bullseye

2019-07-16 Thread Ben Hutchings
On Tue, 2019-07-16 at 11:57 +0200, Raphael Hertzog wrote:
[...]
> The other desktop firewall that I know is "ufw" but it doesn't seem to
> have any momentum behind it.

Also, while its syntax is obviously intended to be simple, it's quite
irregular and the syntax error messages aren't very helpful.

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.




signature.asc
Description: This is a digitally signed message part


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

2019-07-16 Thread 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.



Bug#932237: ITP: py-libzfs -- Python libzfs bindings

2019-07-16 Thread William Grzybowski
Package: wnpp
Severity: wishlist
Owner: William Grzybowski 

* Package name: py-libzfs
  Version : 0.1
  Upstream Author : FreeNAS
* URL : https://github.com/freenas/py-libzfs
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Python libzfs bindings

py-libzfs is a fairly straight-forward set of Python bindings for libzfs for
ZFS on Linux and FreeBSD.

Its a very useful module to deal with ZFS programatically, without relying on
zfs CLI tools.
I plan to maintain it myself.



Re: Cron, anacron, cronie, systemd-timers

2019-07-16 Thread Christian Kastner
On 09.07.19 09:32, Marc Haber wrote:
> It is good to know where things are going. Would you mind if I created
> a wiki page with this road map laid out about where Debian's cron
> world is going?

Not at all, on the contrary -- thanks for the offer!

> That would, though, only make sense if you could find
> the time to cross-read it and add omissions and point out factual
> errors.

Of course.

>> Over the past couple of years, I've spent a considerable amount of
>> effort in converting the format to source format 3.0 (quilt), but I
>> never quite finished and got distracted with other stuff. Nevertheless,
>> I completed this conversion in February. I'll push it over the next few
>> days (I was just waiting for buster to be released before doing anything
>> drastic).
> 
> \o/
> 
> It is good to know that there is considerable work going on, most of
> it being on the source code level, which is unfortunately something I
> cannot be helpful because I'm not a sufficiently good C programmer. I
> was not even aware that vixie cron and cronie share a common code base
> that makes such a migration feasible.

There's a lot of non-C stuff that needs to be done, too, in case you're
interested in that?

For example, I'm almost certain by now that the system crontab file and
dirs (/etc/crontab, /etc/cron.*) need to be moved out into a separate
config package so that alternative cron implementations can use them.
Currently, each implementation ships its own crontabs, and switching
between them (eg: switching from cron to bcron) is a pain.

>> My current plan it to move from vixie cron 3.0pl1-134 directly to a
>> (patched) cronie as soon as possible, so that the default daemon can be
>> switched to cronie in time the next release.
> 
> Great! That is good to know. Are you using a mailing list for this
> effort that I can subscribe to and see where I can be helpful? Or is
> this mainly a one-man show anyway?

There used to be one until the move to salsa, and I'm ashamed to say I
forgot to opt-in to the migration.

I'll set one up for cronie and then report back to this list.

Regards,
Christian



Bug#932216: ITP: bidict -- Efficient, Pythonic bidirectional map implementation and related functionality

2019-07-16 Thread William Grzybowski
Package: wnpp
Severity: wishlist
Owner: William Grzybowski 

* Package name: bidict
  Version : 0.18.0
  Upstream Author : Joshua Bronson 
* URL : https://bidict.readthedocs.io/
* License : MPL-2.0
  Programming Lang: Python
  Description : Efficient, Pythonic bidirectional map implementation and
related functionality

Bidict:
- is in use by several teams at Google, Venmo, CERN, Bank of America Merrill
Lynch, Bloomberg, Two Sigma, and others
- has carefully designed APIs for safety, simplicity, flexibility, and
ergonomics
- is CPython-, PyPy-, Python 2-, and Python 3-compatible
- has extensive test coverage (including property-based tests an d benchmarks)
run continuously on all supported Python versions and OSes
- integrates natively with Python’s collections interfaces
is implemented in concise, well-factored, well-documented pure Python that
leverages a number of advanced language features

It can be used in many applications.
I plan to maintain it within DPMT.


Re: git & Debian packaging sprint report

2019-07-16 Thread Sean Whitton
Hello,

On Tue 16 Jul 2019 at 10:45AM +02, Ansgar Burchardt wrote:

> A "source package" generally consists of:
>  - a set of upstream artifacts (currently one or more tarballs,
>signatures); can be the empty set for native packages
>  - Debian-specific artifacts
>  - the .dsc artifact (generated from the Debian part); consists of:
>- strong cryptographic hashes of all other artifacts
>  (Checksum-*, Files, ...)
>- convenience information extracted from Debian-specific artifacts
>  (Build-Depends, ...)
>
> Currently we represent all of these as real files that need to be
> provided by the uploader.
>
> If you no longer want "source packages" as we have currently, you just
> define another representation as the canonical one.
>
> So I would like to just change how developers can provide artifacts to
> the archive: upstream artifacts can be specified as either a set of
> URLs to retrieve them from or a Git tree; Debian-specific artifacts can
> be a Git tree or (for source format 1.0) a diff between two Git trees.
>
> All artifacts provided must be covered by a strong cryptographic hash
> which is signed by a developer.  The hash must not only cover the Git
> tree object itself, but also all content covered by it.
>
> We currently have "tar" as the serialization format covered by the
> strong cryptographic hash and, as I value having a representation of
> upstream artifacts in the published archive, believe we should continue
> to provide the "tar" files.  However this is not necessary; we could
> instead provide only the Git tree.
>
> Currently this proposal should also allow multi-package repositories,
> packaging-only repositories, packages using multiple upstream
> artifacts, and ensuring Debian uses the same artifact as upstream.  It
> does not require any integrity from the VCS system.
>
> I think the .dsc artifact should eventually be split into the two
> parts: the list of artifacts (together with strong cryptographic hashes
> and where to locate them) signed by the uploader, and the convenience
> information extracted from these.  The second part should be generated
> by the archive software.

This is interesting.  Thank you for explaining.

For the vast majority of packages, the git-debpush/tag2upload system
enables us to do away with a lot of the complexity that you describe
here.  It brings the Debian way of representing, using and transmitting
source artifacts much closer to how upstream projects do things.

I think it is good for Debian development, downstreams and users to be
able to do away with that complexity when it is possible to do so.

We can't apply git-debpush/tag2upload to all packages -- for example,
packages with large binary datafiles which we wouldn't want to check
into git.  Or, as you mention, packages in monorepos.  Perhaps
maintaining those packages could be made easier by implementing
something like your proposal.

In the meantime, let's deploy the tag2upload service, which has already
been coded up, and enable git pushes to upload for the vast majority of
packages.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: git & Debian packaging sprint report

2019-07-16 Thread Sean Whitton
Hello,

On Tue 16 Jul 2019 at 08:37AM -07, Russ Allbery wrote:

> The consensus among all of us was that if you have an opportunity to pick
> something other than SHA-1 when designing a new protocol, you should.  But
> if it's not simple to pick a different hash, SHA-1 preimage resistance is
> reasonable and the other design properties of the system should dominate
> any concern about SHA-1 preimage attacks.  If the system is vulnerable to
> collisions, that's another matter; there are viable SHA-1 collisions.  But
> given the design described, I don't think it is.  (That said, designing
> the system for hash agility if possible is certainly recommended.)

Thanks for this.

tag2upload is equally as hash-agile as git.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: git & Debian packaging sprint report

2019-07-16 Thread Russ Allbery
Scott Kitterman  writes:

> Except that we have different requirements than git.  Git isn't looking
> for security properties from SHA-1, so it's highly likely it'll meet
> their accident avoidance requirements long after it's no longer
> appropriate for security related assertions.

> I don't think adding more SHA-1 in a security sensitive context is a
> good plan.

I talked this over briefly in the security pod at work with some other
security engineers who know more crypto than I do to sanity-check my
initial opinion.

The consensus among all of us was that if you have an opportunity to pick
something other than SHA-1 when designing a new protocol, you should.  But
if it's not simple to pick a different hash, SHA-1 preimage resistance is
reasonable and the other design properties of the system should dominate
any concern about SHA-1 preimage attacks.  If the system is vulnerable to
collisions, that's another matter; there are viable SHA-1 collisions.  But
given the design described, I don't think it is.  (That said, designing
the system for hash agility if possible is certainly recommended.)

-- 
Russ Allbery (r...@debian.org)   



Re: Debian distribution

2019-07-16 Thread Paul Wise
On Tue, Jul 16, 2019 at 7:00 PM Javeed Ahmed wrote:

> can i make my own  os using debian as a base and distribute it?

Yes, but you can also join the Debian project and help us improve the
Debian operating system for your use-cases.

Would you like to share your plans for how you want to change the
Debian operating system?

If you would like to add new packages, check out this page:

https://mentors.debian.net/intro-maintainers

Other ways to contribute to Debian are documented here:

https://www.debian.org/intro/help

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Debian distribution

2019-07-16 Thread Eric Cooper
On Tue, Jul 16, 2019 at 9:44 AM Kyle Edwards 
wrote:
>
> On Tue, 2019-07-16 at 10:22 +, Javeed Ahmed wrote:
> > sir/madam
> > can i make my own  os using debian as a base and distribute it?
>
> Absolutely! Debian is free software, and you are free to use, modify,
> and distribute it for any purpose. Please make sure to follow the rules
> of each package's license (GPL, BSD, etc.), but in general, yes, all of
> these licenses allow modification and redistribution. See:
>
> https://www.debian.org/social_contract#guidelines
>
> for a description of the Debian philosophy of what consitutes "free
> software".


See also https://www.debian.org/derivatives/


Re: Debian distribution

2019-07-16 Thread Kyle Edwards
On Tue, 2019-07-16 at 10:22 +, Javeed Ahmed wrote:
> sir/madam
> can i make my own  os using debian as a base and distribute it?

Absolutely! Debian is free software, and you are free to use, modify,
and distribute it for any purpose. Please make sure to follow the rules
of each package's license (GPL, BSD, etc.), but in general, yes, all of
these licenses allow modification and redistribution. See:

https://www.debian.org/social_contract#guidelines

for a description of the Debian philosophy of what consitutes "free
software".

Kyle



Debian distribution

2019-07-16 Thread Javeed Ahmed
sir/madamcan i make my own  os using debian as a base and distribute it?

Re: default firewall utility changes for Debian 11 bullseye

2019-07-16 Thread Arturo Borrero Gonzalez
On 7/16/19 11:57 AM, Raphael Hertzog wrote:
> Hi,
> 
> I'm replying to your questions but I have also other questions related to
> this fresh transition...
> 
> On Tue, 16 Jul 2019, Arturo Borrero Gonzalez wrote:
>> as you may know, Debian 10 buster includes the iptables-nft utility by 
>> default,
>> which is an iptables flavor that uses the nf_tables kernel subsystem.
>> Is intended to help people migrate from iptables to nftables.
> 
> It is intended that /proc/net/ip_tables_names and
> /proc/net/ip6_tables_names is always empty when you use iptables-nft and
> thus nf_tables under the hood?
> 
> This is breaking fwbuilder at least: 
> https://github.com/fwbuilder/fwbuilder/issues/88
> 

yes, nf_tables does not expose that data into /proc/, it uses a netlink API
which is a better way of interacting with it.

>> Also, I believe the days of using a low level tool for directly configuring 
>> the
>> firewall may be gone, at least for desktop use cases. It seems the industry 
>> more
>> or less agreed on using firewalld [2] as a wrapper for the system firewall.
> 
> What would/should Debian recommend to configure the firewall on the server
> case ?
> 
> I was recommending creating firewall rules with fwbuilder up to now (see
> https://debian-handbook.info/browse/stable/sect.firewall-packet-filtering.html)

The reset_iptables() functions you mentioned in the above issue don't even
replace the rules in an atomic fashion, which is not a good way to work with
firewall rules, specially for wrappers.

firewalld can be useful in server usecases as well. Here is libvirt using
firewalld (and nftables):

https://libvirt.org/firewall.html#fw-firewalld-and-virtual-network-driver

This is all to say that firewalld may be way better that fwbuilder as a general
recommendation.



Re: default firewall utility changes for Debian 11 bullseye

2019-07-16 Thread Raphael Hertzog
Hi,

I'm replying to your questions but I have also other questions related to
this fresh transition...

On Tue, 16 Jul 2019, Arturo Borrero Gonzalez wrote:
> as you may know, Debian 10 buster includes the iptables-nft utility by 
> default,
> which is an iptables flavor that uses the nf_tables kernel subsystem.
> Is intended to help people migrate from iptables to nftables.

It is intended that /proc/net/ip_tables_names and
/proc/net/ip6_tables_names is always empty when you use iptables-nft and
thus nf_tables under the hood?

This is breaking fwbuilder at least: 
https://github.com/fwbuilder/fwbuilder/issues/88

> Also, I believe the days of using a low level tool for directly configuring 
> the
> firewall may be gone, at least for desktop use cases. It seems the industry 
> more
> or less agreed on using firewalld [2] as a wrapper for the system firewall.

What would/should Debian recommend to configure the firewall on the server
case ?

I was recommending creating firewall rules with fwbuilder up to now (see
https://debian-handbook.info/browse/stable/sect.firewall-packet-filtering.html)
but while it's still maintained, it has not had any recent release
and still hasn't native nftables support
(https://github.com/fwbuilder/fwbuilder/issues/17).

> This email contains 2 changes/proposals for Debian 11 bullseye:
> 
> 1) switch priority values for iptables/nftables, i.e, make nftables Priority:
> important and iptables Priority: optional

Ack.

> 2) introduce firewalld as the default firewalling wrapper in Debian, at least 
> in
> desktop related tasksel tasks.

No objection. I think it's high time we have some default firewall
installed in particular with IPv6 getting more widely deployed...

The other desktop firewall that I know is "ufw" but it doesn't seem to
have any momentum behind it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Re: default firewall utility changes for Debian 11 bullseye

2019-07-16 Thread Guillem Jover
Hi!

On Tue, 2019-07-16 at 11:07:15 +0200, Arturo Borrero Gonzalez wrote:
> as you may know, Debian 10 buster includes the iptables-nft utility by
> default, which is an iptables flavor that uses the nf_tables kernel
> subsystem. Is intended to help people migrate from iptables to nftables.

Yeah, this was a great way to migrate, thanks!

> This email contains 2 changes/proposals for Debian 11 bullseye:
> 
> 1) switch priority values for iptables/nftables, i.e, make nftables Priority:
> important and iptables Priority: optional

Ack. We should really be moving towards nftables, which is so much
better in any possible way. I think doing this early would be good
so that we can find any remaining issues (at least in documentation)
about migrating from iptables to nftables.

As mentioned elsewhere, while you can do the change in the packages
you maintain, you'll still need to file an override change request
against ftp.debian.org so that this gets actually modified. :)

> 2) introduce firewalld as the default firewalling wrapper in Debian,
> at least in desktop related tasksel tasks.

I've never used this nor do use a traditional desktop, so have no
opinion on it, and I'm not sure I care deeply TBH. :)

Thanks,
Guillem



default firewall utility changes for Debian 11 bullseye

2019-07-16 Thread Arturo Borrero Gonzalez
Hi there,

as you may know, Debian 10 buster includes the iptables-nft utility by default,
which is an iptables flavor that uses the nf_tables kernel subsystem.
Is intended to help people migrate from iptables to nftables.

For the next release cycle I propose we move this default event further.
As of this email, iptables [0] is Priority: important and nftables [1] is
Priority: optional in both buster and bullseye. The important value means the
package gets installed by default in every Debian install.

Also, I believe the days of using a low level tool for directly configuring the
firewall may be gone, at least for desktop use cases. It seems the industry more
or less agreed on using firewalld [2] as a wrapper for the system firewall.
There are plenty of system services that integrate with firewalld anyway [3].
By the way, firewalld is using (or should be using) nftables by default at this
point.

This email contains 2 changes/proposals for Debian 11 bullseye:

1) switch priority values for iptables/nftables, i.e, make nftables Priority:
important and iptables Priority: optional

2) introduce firewalld as the default firewalling wrapper in Debian, at least in
desktop related tasksel tasks.

For changes in 2) I'm looking forward to have consensus, and will need others to
do changes themselves.
I can do changes in 1) myself, and will probably do very soon.

regards

[0] https://tracker.debian.org/pkg/iptables
[1] https://tracker.debian.org/pkg/nftables
[2] https://tracker.debian.org/pkg/firewalld
[3] disclaimer: I don't use firewalld myself



Re: git & Debian packaging sprint report

2019-07-16 Thread Michael Kesper
Hi Sean,

On 15.07.19 19:02, Sean Whitton wrote:
> On Mon 15 Jul 2019 at 01:16PM +02, Michael Kesper wrote:
> 
>> Nonetheless it seems to me you are moving from trusting local signing
>> to trusting upload by salsa, thereby making salsa more attractive for
>> attackers.
> 
> I don't follow -- the git tag is PGP-signed, locally, by the uploader.
> Just like how they would PGP-sign, locally, the .dsc and .changes.

Ah ok, sorry, this wasn't clear to me.

Michael
 




signature.asc
Description: OpenPGP digital signature


Re: git & Debian packaging sprint report

2019-07-16 Thread Ansgar Burchardt
On Tue, 2019-07-16 at 08:29 +0100, Sean Whitton wrote:
> We also rely on git for security elsewhere.  For example, dak is
> deployed by ftpmasters pushing a signed git tag to salsa; a cronjob on
> ftpmaster then deploys that code.  That's relying on SHA-1 in pretty
> much the same way as tag2upload does, AFAICT.

That is true and I don't like it.  I should probably add a sha2 hash
somewhere.  (Note that we *can* just change it...)

> On Mon 15 Jul 2019 at 10:43PM +02, Ansgar Burchardt wrote:
> > It also has one downside: `git tag` alone won't be enough to generate
> > the required information, but then a special-purpose tool was proposed
> > here already.
> > 
> > The client tool could possibly also just create the .dsc and .changes,
> > except for hashes of the compressed files, and the web service just
> > recreate the tarball and compress them.  That would require near zero
> > trust in the web service, but still allow developers to no longer upload
> > source packages which might be large.  (A bit similar to not having to
> > trust buildds by making packages reproducible.)
> 
> This is certainly an interesting proposal and it would be better for
> users than using dput, as you say.
> 
> An important advantage of the tag2upload solution over such a thing,
> aside from just the fact that it already exists today, is that it allows
> us to move (slowly!) towards replacing source packages with git trees,
> like the rest of the world has.
> 
> git-debpush is such a simple wrapper around git-tag and git-push that
> its users really are uploading only by pushing a signed tag.  Your
> proposal would bake source packages back into the upload process in a
> way that will make it harder to ever get rid of them.

No, my proposal allows to stop generating the "source package" as a set
of real files at any given time.

A "source package" generally consists of:
 - a set of upstream artifacts (currently one or more tarballs,
   signatures); can be the empty set for native packages
 - Debian-specific artifacts
 - the .dsc artifact (generated from the Debian part); consists of:
   - strong cryptographic hashes of all other artifacts
 (Checksum-*, Files, ...)
   - convenience information extracted from Debian-specific artifacts
 (Build-Depends, ...)

Currently we represent all of these as real files that need to be
provided by the uploader.

If you no longer want "source packages" as we have currently, you just
define another representation as the canonical one.

So I would like to just change how developers can provide artifacts to
the archive: upstream artifacts can be specified as either a set of
URLs to retrieve them from or a Git tree; Debian-specific artifacts can
be a Git tree or (for source format 1.0) a diff between two Git trees.

All artifacts provided must be covered by a strong cryptographic hash
which is signed by a developer.  The hash must not only cover the Git
tree object itself, but also all content covered by it.

We currently have "tar" as the serialization format covered by the
strong cryptographic hash and, as I value having a representation of
upstream artifacts in the published archive, believe we should continue
to provide the "tar" files.  However this is not necessary; we could
instead provide only the Git tree.

Currently this proposal should also allow multi-package repositories,
packaging-only repositories, packages using multiple upstream
artifacts, and ensuring Debian uses the same artifact as upstream.  It
does not require any integrity from the VCS system.

I think the .dsc artifact should eventually be split into the two
parts: the list of artifacts (together with strong cryptographic hashes
and where to locate them) signed by the uploader, and the convenience
information extracted from these.  The second part should be generated
by the archive software.

Ansgar



Re: git & Debian packaging sprint report

2019-07-16 Thread Sean Whitton
Hello,

On Mon 15 Jul 2019 at 12:47PM -07, Russ Allbery wrote:

> I'm dubious that we really care that much about a preimage attack on
> SHA-1, [...]

Someone suggested on IRC that such an attack on tag2upload is even less
likely to be possible because each preimage has to be something which
dpkg-source will successfully make into a source package with the same
source package name, version etc.

We also rely on git for security elsewhere.  For example, dak is
deployed by ftpmasters pushing a signed git tag to salsa; a cronjob on
ftpmaster then deploys that code.  That's relying on SHA-1 in pretty
much the same way as tag2upload does, AFAICT.

On Mon 15 Jul 2019 at 10:43PM +02, Ansgar Burchardt wrote:

> It also has one downside: `git tag` alone won't be enough to generate
> the required information, but then a special-purpose tool was proposed
> here already.
>
> The client tool could possibly also just create the .dsc and .changes,
> except for hashes of the compressed files, and the web service just
> recreate the tarball and compress them.  That would require near zero
> trust in the web service, but still allow developers to no longer upload
> source packages which might be large.  (A bit similar to not having to
> trust buildds by making packages reproducible.)

This is certainly an interesting proposal and it would be better for
users than using dput, as you say.

An important advantage of the tag2upload solution over such a thing,
aside from just the fact that it already exists today, is that it allows
us to move (slowly!) towards replacing source packages with git trees,
like the rest of the world has.

git-debpush is such a simple wrapper around git-tag and git-push that
its users really are uploading only by pushing a signed tag.  Your
proposal would bake source packages back into the upload process in a
way that will make it harder to ever get rid of them.

I appreciate that thanks to the SHA-1 thing you don't want to rely on
git trees for much of anything, so this point will not move you, but I
wanted to mention this point about obsoleting source packages for the
benefit of others in the thread.

We can expect git to move off SHA-1 eventually, and it is not at all
clear the threat from preimage attacks is sufficient for it to be wise
for us to hold ourselves back here.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: git & Debian packaging sprint report

2019-07-16 Thread Peter Wienemann
On 15.07.19 22:50, Russ Allbery wrote:
> At some point, Git itself will switch away from SHA-1, and we
> can then obviously follow.

According to [0]:

-
"Git v2.13.0 and later subsequently moved to a hardened SHA-1
implementation by default, which isn't vulnerable to the SHAttered
attack.

Thus Git has in effect already migrated to a new hash that isn't SHA-1
and doesn't share its vulnerabilities, its new hash function just
happens to produce exactly the same output for all known inputs,
except two PDFs published by the SHAttered researchers, and the new
implementation (written by those researchers) claims to detect future
cryptanalytic collision attacks."
-

The document also outlines plans for a transition to SHA256. It actually
seems that since git version 2.21.0 the first SHA256 implementations
have entered the git code [1, 2]. Though I have no idea whether using
SHA256 is already production-ready.

Therefore I think that distrust in SHA1 is no reason to discard Sean's
and Ian's debpush proposal.

Peter

[0]
https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt

[1]
https://github.com/git/git/commit/33e4ae9c509e0ecdc6508475f2974d275539616e

[2]
https://github.com/git/git/commit/27dc04c54506967fcaa87b2d560547ee5633040c