Re: Facilitating external repositories

[Paul Wise]

On Sun, Jun 7, 2015 at 11:49 AM, Chris Knadle wrote:

> I recall the prior DPL wanting to support PPAs in Debian, and I would
> imagine that this issue is one of the "sticking points" to that idea.

The Debian PPA proposal will be different to Launchpad PPAs and will
be signed by the same keys as the rest of the archive.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
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/caktje6eccqz0jkbxf_h_txxxsddmjfg3s3e6vuk3f+umhr0...@mail.gmail.com

DEB_SIGN_KEYID vs DEBSIGN_KEYID

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi folks,

Trying to get rid of my old GPG key I stumbled over this:

For devscripts you can define a variable "DEBSIGN_KEYID". For
dpkg it is called "DEB_SIGN_KEYID". git-buildpackage doesn't
support a keyid environment variable at all, as it seems. All
ignore the default-key option set in .gnupg/gpg.conf .

Would it be possible to get a common line here?


Thanx in advance
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVdAKZAAoJEAqeKp5m04HLtWIH/ilKMAmWhtOgEQhYYg0HejVR
xLvxAI2LJTpMI9Z2EkTwKjU0tVQNOJlupBlO42h3pt3zFNMgQkQPwlS6bNnNue34
HHutVmo+9/ONz7aigIzUuELjNmk4DR/9UXWweUM+A/oDSwJx5Q/i05aPu0pOC7Wx
Sr9YGYznz1PTkoWqZ/2OJTdAGIhN801ElFt22hkykVDJwoqJym9bdEVQkrm90lky
lINvsFokS7rmMrvHFOMFJ5Bpp2MN4HLvwba0qzwxPs9m2hSpFUvRRMAxWYjtzi4l
7CqyAjub+GRgqGZuDFQlDZM5efmeSNe8y6B95BlenE0ORAbDm5bGbZOVyz+1VCc=
=IXqs
-END PGP SIGNATURE-


-- 
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/55740299.1040...@afaics.de

Re: Facilitating external repositories

[Wouter Verhelst]

On Fri, Jun 05, 2015 at 09:10:56AM -0700, Josh Triplett wrote:
> Wouter Verhelst wrote:
> > At $DAYJOB, I'm maintaining a few repositories with ready-to-install
> > packages for a number of distributions[1]
> > 
> > Currently, the instructions[2] say to do the following:
> > - Download and install an "eid-archive" package, which contains the GPG
> >   keys and generates a sources.list.d file for the repository;
> > - Run "apt-get update";
> > - Install the "eid-mw" and/or "eid-viewer" packages.
> > 
> > This works, but it has a number of downsides:
> > - The second step, "run apt-get update", is often overlooked; this seems
> >   to be the case especially for users of Ubuntu, where the default
> >   handler for installing packages is the "Software Center", a GUI
> >   software management tool that doesn't have any UI element for doing
> >   (the equivalent of) apt-get update
> > - There is no trust path from your already-installed distribution to the
> >   "archive" package (yes, I did sign the gpg keys; no, I don't consider
> >   that enough).
> > - It still requires users to manually install packages.
> 
> Given that the packages in question appear to be Free Software (at least
> from a quick check of a couple of them, as well as the repository being
> named "main"),

Correct, it's all under GPLv3.

> is there a reason you don't maintain them in Debian
> (including backports or volatile if you need to provide the newest
> packages for older distributions)?

As others have pointed out, the said software used to be in Debian (I
was its maintainer). The reasons for pulling it were long, complicated,
and boring; suffice to say that there were some practical problems.

(the ftp.d.o bug says "no reply from maintainer", which is only half the
story. At the time I was aware of issues starting to build around beid,
and trying to figure out how to fix them; I should've probably replied,
but it occurred to me that pulling was probably a good strategy, at
least in the short term)

> If that's not an option for some reason, then given that the packages
> are Free Software and of reasonably broad interest, you could at least
> upload a package to Debian containing the archive key, similar to
> pkg-mozilla-archive-keyring; that would establish a trust path.  (Which
> doesn't solve the usability problem, but it does solve the trust
> problem.)

True, but I don't think it is the best way forward.

First, it would work for me, as long as I'm still contracting for the
government[1]. However, due to it being a *government* contract, this is
an inherently time-limited situation[2]. I want this situation to remain
manageable after the end of my contract.

Second, while I wrote this in response to an immediate issue that I'm
dealing with, it should obvious that this isn't a problem specific to my
situation; I would prefer to have a situation which works for everyone,
not just for me. Having to maintain a package inside Debian isn't the
best solution for third-party developers.

Third, this wouldn't scale very well. I think the
pkg-mozilla-archive-keyring is special in that it contains pre-release
packages of software already in Debian, maintained by the same people
who maintain that software in Debian. This is not the case for my
software, and presumably also not for many other third-party
repositories.

Finally, requiring third-party developers to upload an archive keyring
into Debian does not scale very well.

Other operating systems (Windows, OSX) have a way for third-party
developers to get a key signed which is then allowed to install software
without big red flashing security warnings. I think it would make sense
for us to have something similar. We currently don't; in fact, when you
install something that isn't signed, you *don't* get big red flashing
security warnings; I think that's wrong, and that we should do so.

[1] Technically, I'm not contracting for the government, there's a
middle man in there somewhere, but let's keep the pesky little
details out of it, shall we? ;-)
[2] Belgian law says that while the government can employ contractors,
every few years the contract has to be renegotiated; at that point I
could continue working, or someone else could win the contract and
take over.

> I don't think you can have a dpkg trigger run apt update, since dpkg
> will typically be invoked under the apt lock.

Actually, I believe the story is that apt wants to invoke the dpkg lock
;-)

At any rate, no, that doesn't work. Yes, I tried.

> However, a higher-level
> package manager that doesn't support manual updates could probably learn
> to do an update when sources.list{,.d/*} gets updated.
> 
> > I note that other third-party developers often provide a single debian
> > package that can be installed, where the binary package itself already
> > contains repository configuration that gets installed. This method
> > works for application software, but (as in my case) if the intent is to
> > provide a l

Re: Facilitating external repositories

[Wouter Verhelst]

Hi Chris,

On Sat, Jun 06, 2015 at 11:49:21PM -0400, Chris Knadle wrote:
> Hey, Wouter.
> 
> On 06/04/2015 12:18 PM, Wouter Verhelst wrote:
> > Hi,
> > 
> > At $DAYJOB, I'm maintaining a few repositories with ready-to-install
> > packages for a number of distributions[1]
> > 
> > Currently, the instructions[2] say to do the following:
> > - Download and install an "eid-archive" package, which contains the GPG
> >   keys and generates a sources.list.d file for the repository;
> > - Run "apt-get update";
> > - Install the "eid-mw" and/or "eid-viewer" packages.
> > 
> > This works, but it has a number of downsides:
> > - The second step, "run apt-get update", is often overlooked; this seems
> >   to be the case especially for users of Ubuntu, where the default
> >   handler for installing packages is the "Software Center", a GUI
> >   software management tool that doesn't have any UI element for doing
> >   (the equivalent of) apt-get update
> 
> Huh... this is unfortunate.  I can imagine a package that installs some
> kind of one-time cronjob that will execute 'apt-get update' a minute
> later, but I don't like the idea... I hope there's something better
> available.

I could use an "at" job, but that isn't part of the essential set or
installed by default (nor is cron) on some derivatives, so that doesn't
help.

> > - There is no trust path from your already-installed distribution to the
> >   "archive" package (yes, I did sign the gpg keys; no, I don't consider
> >   that enough).
> 
> Yeah unfortunately this is sort of a catch-22 problem... IMHO we want an
> external archive key to be easily replaceable in case it's ever
> compromised, yet we also want that same key to be "easily trust-able",
> which takes time and several signatures of known keys to do... i.e. an
> investment.
> 
> I recall the prior DPL wanting to support PPAs in Debian, and I would
> imagine that this issue is one of the "sticking points" to that idea.
> 
> BTW does the 'debian-keyring' package exist on Ubuntu and Mint?

Yes.

> If so I could imagine that your eid-archive package could have a
> pre-depends on debian-keyring and check that GPG keys installed by
> eid-archive are signed by a DD or DM.

That doesn't fix the trust issue.

Any trust checks need to be done by something which has first been
verified to be trusted code. If you have a package test its own
trustworthiness, then that code is running before its trust has been
checked, and therefore the trust check is worthless.

Think about it. A malicious package could just claim to be
trustworthy... 

So, for there to be a valid trust path, the trust needs to be verified
by something inside the Debian archive.

I had indeed been thinking about a tool which would verify that a GPG
key is signed by at least one person inside the debian keyring, and if
so, enable the archive and possibly do an apt-get update and maybe
install a default set of software provided in the configuration file
(which would need to be signed too, for this to be safe). Such a tool
could register a mime type for a particular format of configuration file
that it understands, which would allow a repository maintainer to add
something to a website which a user can download and automatically open
inside this tool.

That would solve the usability issue ("click on a link, tell browser
to open with default program, everything else is automatic"), and would
sign the trust issue (since it is code inside the Debian archive which
does all the verification). However, I wanted to check first whether
something along those lines already existed.

It now appears that it does not, so I'll have to start hacking.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


signature.asc
Description: Digital signature

Re: Facilitating external repositories

[Wouter Verhelst]

On Sat, Jun 06, 2015 at 01:48:12PM +0800, Paul Wise wrote:
> On Sat, Jun 6, 2015 at 8:13 AM, Brian May wrote:
> 
> > the software is far to volatile (e.g. important bug fixes on a weekly basis)
> 
> We have a place for such software: experimental
> 
> > I don't want old versions hanging around any longer then absolutely required
> 
> We have a place for such software: experimental

That only works for people who have rights to upload something to the
Debian archive. Do we really want to force all third-party developers to
become DMs or DDs?

Also, there are things too volatile even for experimental -- e.g.,
https://files.eid.belgium.be/debian/continuous contains the results of
our CI builds (signed by a different key); while useful for me and
people interested in following along with what's going to happen, this
is hardly something that should be uploaded to experimental.

(in my specific case, there is also a general feeling that the Belgian
Government shouldn't point its citizens to something not compiled by
systems inside government premises and/or signed by a third party)

[...]
> > I note the original poster mentioned Ubuntu PPAs and add-apt-repository; my
> > understanding is that these don't solve the trust issue, I seem to recall
> > the user is shown a fingerprint and asked to confirm it is correct (based on
> > what???) - however I don't have an Ubuntu box I can test this on right now.
> 
> I would guess based on the OpenPGP web of trust or the user's trust in
> their OS that trusts the SSL CA that signed the Launchpad certs.

I hadn't actually looked in detail at whether add-apt-repository solves
the trust issue for PPA's; I just note that due to the fact that
Ubuntu's PPA's are all on the same system, it is in theory at least
possible for it to check the trust path.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
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/20150607092724.gb7...@grep.be

Bug#787977: ITP: smrtanalysis -- software suite for single molecule, real-time sequencing

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: smrtanalysis
   Version : 2.3.0
   Upstream Author : Pacific Biosciences 
* URL : http://pacbiodevnet.com
* License : BSD
   Programming Lang: C++, Python, R
   Description : software suite for single molecule, real-time 
sequencing


  SMRT® Analysis is a powerful, open-source bioinformatics software suite
  available for analysis of DNA sequencing data from Pacific Biosciences’
  SMRT technology.
  .
  Users can choose from a variety of analysis protocols that utilize 
PacBio®
  and third-party tools. Analysis protocols include de novo genome 
assembly,
  cDNA mapping, DNA base-modification detection, and long-amplicon 
analysis to

  determine phased consensus sequences.


This is intended as a metapackage to depend on all the components of
SMRTAnalysis, which are managed in separate SCM repositories at
. It will be maintained by
the Debian Med team at
http://anonscm.debian.org/cgit/debian-med/smrtanalysis.git

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name


--
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/55741658.9030...@ghraoui.name

Bug#787981: ITP: python-pbcore -- Python library for processing Pacific Biosciences data, files

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-pbcore
  Version : 1.0.0
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/pbcore
* License : BSD
  Programming Lang: Python
  Description : Python library for processing Pacific Biosciences 
data files


The pbcore package provides Python modules for processing Pacific 
Biosciences

data files and building PacBio bioinformatics applications. These modules
include tools to read/write PacBio data formats, sample data files for
testing and debugging, base classes, and utilities for building 
bioinformatics applications.

.
This package is part of the SMRTAnalysis suite ( 
 )


Maintenance will be by the Debian Med team at
Vcs-Git: git://anonscm.debian.org/debian-med/python-pbcore.git
Vcs-Browser: http://anonscm.debian.org/cgit/debian-med/python-pbcore.git

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name


--
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/55741d52.8080...@ghraoui.name

ppp plugins and dependencies

[Chris Boot]

Hi all,

Apologies for the long email, but there's a lot to discuss on the topic.

Marco d'Itri and I recently agreed that I would take over maintenance of
ppp. Thanks for all your hard work over the years keeping this package
going, Marco.

One of the first tasks on my list is to resolve the issue with
dependencies and ABI compatibility surrounding the building of ppp
plugins. Several packages in the archive use the ppp-dev package to help
them build ppp plugins that are loaded into pppd at run-time using
dlopen(). The plugins are generally installed into a particular
versioned directory on the filesystem (currently
/usr/lib/pppd/${abi_version}/) where pppd looks for them by default.

There is currently no mechanism for binary packages to depend on a
particular ppp plugin ABI version being available, other than manually
creating (and maintaining) dependencies such as:

Depends: [...] ppp (>= 2.4.6~), ppp (<< 2.4.7~) [...]

This is easy to get wrong (in fact, only network-manager-pptp appears to
get it even nearly right), is a pain to maintain by hand, and is
impossible for the release team to track sensibly with the transition
tracker.

I want to fix this. I'd like to upload the new upstream release 2.4.7
soon, but when I do this all the packages that build plugins will
silently break. Last time we went through this pain I had to work with
the maintainers to get fixed versions uploaded; I know I can't get away
with it this time either, but perhaps we can make it better for next
time especially now that ppp has gained momentum upstream again.

The main problem that I see is that there isn't a built-in mechanism for
tracking such a situation, as far as I can tell. There aren't any shared
libraries involved, so I don't have the benefit of sonames, symbols
files or symbol versioning.

It seems I the way to resolve this might well be by using a
"pppapi-${upstream_version}" virtual package (or perhaps a newfangled
versioned Provides / virtual package). This appears to work for Apache,
Perl and PHP among others. The disadvantage of this is that currently
pppd is not a Depends for all the packages that build ppp plugins,
unlike Apache/Perl/PHP are for their plugins.

network-manager only has pppd as a Recommends despite shipping a pppd
plugin. fso-gsmd ships ppp2fsogsmd.so and yet has no dependency on pppd
whatsoever. Clearly, either those packages need to change or I cannot
rely on a Depends relationship on pppapi-$foo.

A ppp plugin is no use on its own, but could easily be installed and
simply go unused without pppd installed. What definitely doesn't work is
a ppp plugin built for a different version of pppd - the result will
either fail to load (due to pppd's built-in version check or being in
the wrong directory) or crash/misbehave due to an ABI incompatibility.

What's the best way to handle this?

I was also considering writing a debhelper plugin and/or dh_ppp_plugin
script to help with calculating the correct dependencies at build time,
so that packages can simply invoke the script at build-time and Do The
Right Thing. It could also be used to obtain the correct plugin
directory to install plugins into, which seems like it would be useful
for network-manager-pptp among others. Does this sound like a useful
addition?

Lastly, pppd has a built-in mechanism for checking that loaded plugins
are built for the correct version of pppd. It does this by looking up a
pppd_version symbol and comparing it against its own version. Currently
this check is optional, and is used by all the listed packages (below)
except fso-gsmd. If it's not used, pppd prints a warning and carries on
regardless. I wonder about making this version check a requirement to
avoid silent ABI breakage in future. Thoughts?

I very much look forward to everyone's input on these issues.

If you'd like to see what's cooking so far for the next upload of ppp,
please feel free to have a poke around the 'develop' branch in
collab-maint/pkg-ppp.git [1]. All comments gratefully received.

1:
http://anonscm.debian.org/cgit/collab-maint/pkg-ppp.git/log/?h=develop

Thanks,
Chris

Affected maintainers and source packages:

Christoph Biedl 
   pptpd

Debian FreeSmartphone.Org Team 
   fso-gsmd

Jan-Michael Brummer 
   isdnutils (U)

Michael Biebl 
   network-manager (U)
   network-manager-pptp (U)

Rico Rommel 
   fso-gsmd (U)

Rolf Leggewie 
   isdnutils

Sebastian Reichel 
   fso-gsmd (U)

Simon Busch 
   fso-gsmd (U)

Sjoerd Simons 
   network-manager (U)

Utopia Maintenance Team 
   network-manager
   network-manager-pptp

-- 
Chris Boot
deb...@bootc.net
GPG: 8467 53CB 1921 3142 C56D  C918 F5C8 3C05 D9CE 




signature.asc
Description: OpenPGP digital signature

Re: ppp plugins and dependencies

[Jakub Wilk]

* Chris Boot , 2015-06-07, 11:26:

Depends: [...] ppp (>= 2.4.6~), ppp (<< 2.4.7~) [...]


The tildes are pointless here.
s/~//g

--
Jakub Wilk


--
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/20150607104828.ga1...@jwilk.net

Re: ppp plugins and dependencies

[Michael Biebl]

Am 07.06.2015 um 12:26 schrieb Chris Boot:
> network-manager only has pppd as a Recommends despite shipping a pppd
> plugin.

Small correction: network-manager has a versioned Recommends and a
versioned Breaks against ppp.
This is deliberate, since network-manager does not strictly need ppp.
The versioned Breaks is there to ensure that breakage due to a new ppp
upstream version with changed plugin path does not go unnoticed.
Unfortunately it seems ppp changes its plugin dir with every new
upstream release.


network-manager-pptp is different, since this network-manager plugin
strictly requires ppp, so it uses a versioned Depends.

> I was also considering writing a debhelper plugin and/or dh_ppp_plugin
> script to help with calculating the correct dependencies at build time,
> so that packages can simply invoke the script at build-time and Do The
> Right Thing. It could also be used to obtain the correct plugin
> directory to install plugins into, which seems like it would be useful
> for network-manager-pptp among others. Does this sound like a useful
> addition?

Shipping a .pc file upstream to get the correct plugin directory (and
build flags) sounds like a useful addition.


The question I would ask myself, is if ppp has to break the ABI for its
plugins with each new upstream release? Is there actually an ABI break
in 2.4.7?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: ppp plugins and dependencies

[Michael Biebl]

Am 07.06.2015 um 12:49 schrieb Michael Biebl:
> Am 07.06.2015 um 12:26 schrieb Chris Boot:
>> network-manager only has pppd as a Recommends despite shipping a pppd
>> plugin.
> 
> Small correction: network-manager has a versioned Recommends and a
> versioned Breaks against ppp.
> This is deliberate, since network-manager does not strictly need ppp.
> The versioned Breaks is there to ensure that breakage due to a new ppp
> upstream version with changed plugin path does not go unnoticed.

Sorry, the versioned Breaks: ppp (<< 2.4.6) obviously only helps too
ensure that a recent enough version of ppp is installed. It doesn't
guard against breakage due to new ppp upstream releases.
I guess I would have to add a Breaks: ppp (>= 2.4.7) for that

Thinking about this, something like this could be useful for such
situations:
Breaks: != ppp-abi-version-2.4.6
as counterpart to
Depends: = ppp-abi-version-2.4.6



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#787982: ITP: python-pbh5tools -- tools for manipulating HDF5 files produced by, Pacific Biosciences sequencing instruments

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-pbh5tools
  Version : 0.8.0
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/pbh5tools
* License : BSD
  Programming Lang: Python
  Description : tools for manipulating HDF5 files produced by 
Pacific Biosciences sequencing instruments


This package provides functionality for manipulating and extracting data
from cmp.h5 and bas.h5 files produced by the Pacific Biosciences sequencers.
cmp.h5 files contain alignment information while bas.h5 files contain
base-call information.
.
This package is part of the SMRTAnalysis suite (
 )


Maintenance will be by the Debian Med team at
Vcs-Git: git://anonscm.debian.org/debian-med/python-pbh5tools.git
Vcs-Browser: http://anonscm.debian.org/cgit/debian-med/python-pbh5tools.git

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name


--
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/557420ff.80...@ghraoui.name

Re: ppp plugins and dependencies

[Paul Wise]

On Sun, Jun 7, 2015 at 7:00 PM, Michael Biebl wrote:

> Thinking about this, something like this could be useful for such
> situations:
> Breaks: != ppp-abi-version-2.4.6
> as counterpart to
> Depends: = ppp-abi-version-2.4.6

I'm not sure you can do the Breaks part of that as it would have to be
like this:

Breaks: ppp-abi-version-2.4.4, ppp-abi-version-2.4.5,
ppp-abi-version-2.4.7, ppp-abi-version-2.4.8...

I don't know if versioned provides work well enough to do this, but how about:

Provides: ppp-abi (= N)

Breaks: ppp-abi (!= N)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
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/CAKTje6GTX2M2QyNVWN-Z1aN7dBa=cytk+ntn1abgwrx5j+p...@mail.gmail.com

Re: ppp plugins and dependencies

[Chris Boot]

On 07/06/15 11:49, Michael Biebl wrote:
> Am 07.06.2015 um 12:26 schrieb Chris Boot:
>> network-manager only has pppd as a Recommends despite shipping a pppd
>> plugin.
> 
> Small correction: network-manager has a versioned Recommends and a
> versioned Breaks against ppp.
> This is deliberate, since network-manager does not strictly need ppp.
> The versioned Breaks is there to ensure that breakage due to a new ppp
> upstream version with changed plugin path does not go unnoticed.
> Unfortunately it seems ppp changes its plugin dir with every new
> upstream release.

Upstream ppp not only changes the plugin directory name but also the
value of the VERSION #define, which goes into pppd_version that pppd
looks at.

I agree that network-manager doesn't strictly need pppd to operate, and
a versioned Breaks is sufficient for this particular situation. This is
why I wanted to strike up discussion about this - we need a way of
dealing with these dependencies in such a way that works for everyone
while causing the least disruption.

[ from your follow-up ]
> Sorry, the versioned Breaks: ppp (<< 2.4.6) obviously only helps too
> ensure that a recent enough version of ppp is installed. It doesn't
> guard against breakage due to new ppp upstream releases.
> I guess I would have to add a Breaks: ppp (>= 2.4.7) for that
> 
> Thinking about this, something like this could be useful for such
> situations:
> Breaks: != ppp-abi-version-2.4.6
> as counterpart to
> Depends: = ppp-abi-version-2.4.6

We can't do that quite, but this could perhaps be achieved with a
versioned virtual package such as (for ppp-2.4.7):

Breaks: ppp-plugin-abi (<< 2.4.7), ppp-plugin-abi (>> 2.4.7)

I don't see a != declared in the Debian Policy Manual section 7.1
either, which might have helped to condense this a bit.

Nobody wants to manage these types of dependencies by hand though, do they?

>> I was also considering writing a debhelper plugin and/or dh_ppp_plugin
>> script to help with calculating the correct dependencies at build time,
>> so that packages can simply invoke the script at build-time and Do The
>> Right Thing. It could also be used to obtain the correct plugin
>> directory to install plugins into, which seems like it would be useful
>> for network-manager-pptp among others. Does this sound like a useful
>> addition?
> 
> Shipping a .pc file upstream to get the correct plugin directory (and
> build flags) sounds like a useful addition.

Upstream's build system is... archaic. It doesn't autotools and its
configure script is hand-built and does its own templating. I don't
think there's much scope for adding pkg-config upstream, sadly.

> The question I would ask myself, is if ppp has to break the ABI for its
> plugins with each new upstream release? Is there actually an ABI break
> in 2.4.7?

There probably doesn't need to be an ABI break for every version, but
there is with 2.4.6 => 2.4.7 due to the addition of some variables. If
this was a shared library it wouldn't necessitate a soname bump as it's
essentially just a new symbol, but a plugin that happens to use this new
symbol would break badly on an older pppd.

Cheers,
Chris

-- 
Chris Boot
bo...@bootc.net



signature.asc
Description: OpenPGP digital signature

Re: ppp plugins and dependencies

[Simon McVittie]

On 07/06/15 12:35, Chris Boot wrote:
> On 07/06/15 11:49, Michael Biebl wrote:
>> Shipping a .pc file upstream to get the correct plugin directory (and
>> build flags) sounds like a useful addition.
> 
> Upstream's build system is... archaic. It doesn't autotools and its
> configure script is hand-built and does its own templating. I don't
> think there's much scope for adding pkg-config upstream, sadly.

.pc files without Autotools are pretty easy: all you really need is some
way to substitute the variables that dependent packages ought to use.
For instance pppd/Makefile.linux could do this:

pppd.pc: pppd.pc.in Makefile
sed -e 's![@]plugindir[@]!${LIBDIR}!' \
-e 's![@]pppd[@]!${BINDIR}/pppd!' \
-e 's![@]includedir[@]!${INCDIR}!' \
-e 's![@]VERSION[@]!${VERSION}!' \
< $< > $@

with pppd.pc.in containing something like this:

plugindir=@plugindir@
pppd=@pppd@
includedir=@includedir@

Name: pppd
Description: PPP daemon
Requires:
Version: @VERSION@
Cflags: -I${includedir}

and the definition of LIBDIR copied from pppd/plugins/Makefile.linux
into pppd/Makefile.linux.

Then you could use `pkg-config --cflags pppd`, `pkg-config
--variable=plugindir pppd`, `pkg-config --variable=pppd pppd` to get the
necessary information.

(This is untested and might contain errors, but you get the idea. I'm
assuming that Makefile is dynamically created with @SUBSTITUTIONS@
substituted, like it is for Autotools - if it isn't, the dependency
might need adjustment.)

S


-- 
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/5574345a.9050...@debian.org

Upstream and packaging

[Geert Stappers]

Hi,

What about creating a guide line where upstream creates a directory
Packaging where sub directories are like Debian, Ubuntu, Mint,
Redhat, CentOS, Suse and such?

So Upstream can ship their tar-balls / git repositories with
the package stuff ( Spec files, debian/ directories ) allready available.
Next distro have that way a starting point for their packaging.

My reason for such guide line is that I'm now bitten by our policy
that upstream should NOT include a debian directory in the top directory
and there is allready done packaging.

Does such a guide line allready exist?


Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: Digital signature

Re: Upstream and packaging

[Niels Thykier]

On 2015-06-07 14:17, Geert Stappers wrote:
> 
> Hi,
> 
> What about creating a guide line where upstream creates a directory
> Packaging where sub directories are like Debian, Ubuntu, Mint,
> Redhat, CentOS, Suse and such?
> 
> So Upstream can ship their tar-balls / git repositories with
> the package stuff ( Spec files, debian/ directories ) allready available.
> Next distro have that way a starting point for their packaging.
> 
> My reason for such guide line is that I'm now bitten by our policy
> that upstream should NOT include a debian directory in the top directory
> and there is allready done packaging.
> 
> Does such a guide line allready exist?
> 
> 
> Groeten
> Geert Stappers
> 

Hi,

I am not entirely sure that advice is still valid.  As I recall, the
"3.0 (quilt)" effectively mitigates that problem - by deleting the
entire "debian/" provided by upstream before extracting the debian.tar.$comp

~Niels



-- 
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/55743a5a.4010...@thykier.net

Re: ppp plugins and dependencies

[Michael Biebl]

Am 07.06.2015 um 13:35 schrieb Chris Boot:
> On 07/06/15 11:49, Michael Biebl wrote:
>> Thinking about this, something like this could be useful for such
>> situations:
>> Breaks: != ppp-abi-version-2.4.6
>> as counterpart to
>> Depends: = ppp-abi-version-2.4.6
> 
> We can't do that quite, but this could perhaps be achieved with a
> versioned virtual package such as (for ppp-2.4.7):
> 
> Breaks: ppp-plugin-abi (<< 2.4.7), ppp-plugin-abi (>> 2.4.7)
> 
> I don't see a != declared in the Debian Policy Manual section 7.1
> either, which might have helped to condense this a bit.

The != syntax was just an idea, nothing which exists in code or policy
ttbomk.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: ppp plugins and dependencies

[James McCoy]

On Sun, Jun 07, 2015 at 11:26:12AM +0100, Chris Boot wrote:
> One of the first tasks on my list is to resolve the issue with
> dependencies and ABI compatibility surrounding the building of ppp
> plugins. Several packages in the archive use the ppp-dev package to help
> them build ppp plugins that are loaded into pppd at run-time using
> dlopen(). The plugins are generally installed into a particular
> versioned directory on the filesystem (currently
> /usr/lib/pppd/${abi_version}/) where pppd looks for them by default.
> 
> There is currently no mechanism for binary packages to depend on a
> particular ppp plugin ABI version being available, other than manually
> creating (and maintaining) dependencies such as:
> 
> Depends: [...] ppp (>= 2.4.6~), ppp (<< 2.4.7~) [...]

This sounds like the same issue I brought up in
<20150422234712.gc19...@freya.jamessan.com>.  We, as a distribution,
haven't solved the problem of ensuring

a) Packages which dynamically load a shared library are rebuilt when
   appropriate
b) After such a rebuild, the package loading the shared library and the
   shared library are upgraded together

while still avoiding the use of hard Depends (since they defeat the
purpose of dynamically loading a library).

This has been solved for programs which just dynamically link libraries
through binNMUs and symbols/shlibs files, but we really need a similar
mechanism for dynamically loaded libraries.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Re: Issue with PTS watch file service

[Andreas Tille]

Hi Daniel,

On Fri, Jun 05, 2015 at 01:24:14PM +0200, Daniel Leidert wrote:
> Hi,
> 
> Is it possible, that the watch file service of our PTS has some issue
> atm? The PTS spuriously reports "temporary or permanent problems" for
> some projects, although the watch files look perfectly ok to me and
> uscan does work as expected. Some examples:
> 
> https://packages.qa.debian.org/a/abgate.html (sf.net)
> https://packages.qa.debian.org/a/amsynth.html (github)
> https://packages.qa.debian.org/c/calf.html (sf.net)
> https://qa.debian.org/developer.php?login=debichem-de...@lists.alioth.debian.org
>  (sf.net, other)
> 
> For the latter many of the sf.net based projects are missing the
> upstream version in the output.

Wild guess:  It migth be connected to the fact that DEHS is not working
properly any more as it was mentioned here on Debian-QA list[1].

> Please feel free to forward this to the correct address.

If I were you I would ask on debian-qa.

Kind regards

  Andreas.


[1] https://lists.debian.org/debian-qa/2015/05/msg00068.html

-- 
http://fam-tille.de


-- 
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/20150607145254.ge21...@an3as.eu

Bug#787991: ITP: gmt-dcw -- Digital Chart of the World (DCW) for GMT

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 

* Package name: gmt-dcw
  Version : 1.1.1
  Upstream Author : Paul Wessel 
* URL : http://www.soest.hawaii.edu/pwessel/dcw/index.html
* License : LGPL-3+
  Programming Lang: N/A
  Description : Digital Chart of the World (DCW) for GMT

DCW-GMT is an enhancement to the original 1:1,000,000 scale vector basemap
of the world available from the Princeton University Digital Map and
Geospatial Information Center and from GeoCommunity at
http://data.geocomm.com/readme/dcw/dcw.html.
This data is for use by GMT, the Generic Mapping Tools.


The package is required for GMT 5 and will be maintained along with the
other gmt packages in the Debian GIS team.


-- 
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/20150607142412.30645.620.report...@osiris.linuxminded.xs4all.nl

Re: Issue with PTS watch file service

[Paul Wise]

On Sun, Jun 7, 2015 at 10:52 PM, Andreas Tille wrote:

> Wild guess:  It migth be connected to the fact that DEHS is not working
> properly any more as it was mentioned here on Debian-QA list[1].

DEHS died many years ago, the timing is more likely to be caused by
upgrades to jessie. IIRC multiple services sprung up to replace DEHS.
I don't know which of them are still operating and which of those are
behind the PTS. Someone would have to spend time tracing which data
goes where to figure this out, but I'm willing to bet it is due to
jessie regressions in SSL stuff, leading to more workarounds needing
to be added. I did a bunch of that for the easy stuff on qa.d.o and
the PTS already. People who know about watch stuff and could probably
fix this are Bart Martens and or UDD and or Mole people.

https://wiki.debian.org/ServicesSSL

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
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/CAKTje6EN0kEwpi+7gqxpK=bZJVNn+jm3ZLThykvt51H=hrh...@mail.gmail.com

Re: Facilitating external repositories

[Kurt Roeckx]

On Thu, Jun 04, 2015 at 06:18:16PM +0200, Wouter Verhelst wrote:
> - There is no trust path from your already-installed distribution to the
>   "archive" package (yes, I did sign the gpg keys; no, I don't consider
>   that enough).

There are 2 popular methods for this:
- Have an "app store".  We would allow those 3rd parties to upload
  and we sign it.  You would probably be looking for a part of the
  archive that doesn't have the same schedule as the releases.
- Have a method for 3rd parties to get their key to be trusted to
  installed software.  This could potentionally be done by either
  shipping all such trusted keys or have them signed by a special
  purpose key.


Kurt


-- 
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/20150607154108.ga29...@roeckx.be

Bug#787994: ITP: gmt-gshhg -- Global Self-consistent Hierarchical High-resolution Geography (GSHHG)

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 

* Package name: gmt-gshhg
  Version : 2.3.4
  Upstream Author : Paul Wessel 
* URL : http://www.soest.hawaii.edu/pwessel/gshhg/index.html
* License : LGPL-3+
  Programming Lang: N/A
  Description : Global Self-consistent Hierarchical High-resolution 
Geography (GSHHG)

GSHHG is a high-resolution shoreline data set amalgamated from two databases:
Global Self-consistent Hierarchical High-resolution Shorelines (GSHHS) and
CIA World Data Bank II (WDBII). GSHHG contains vector descriptions at five
different resolutions of land outlines, lakes, rivers, and political
boundaries. This data is for use by GMT, the Generic Mapping Tools.


This package replaces gmt-gshhs and is required for GMT 5, it will be
maintained along with the other gmt packages in the Debian GIS team.


-- 
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/20150607154652.9267.42703.report...@osiris.linuxminded.xs4all.nl

Re: Facilitating external repositories

[Bálint Réczey]

Hi Wouter,

2015-06-07 11:08 GMT+02:00 Wouter Verhelst :
> On Fri, Jun 05, 2015 at 09:10:56AM -0700, Josh Triplett wrote:
>> Wouter Verhelst wrote:
>> > At $DAYJOB, I'm maintaining a few repositories with ready-to-install
>> > packages for a number of distributions[1]
>> >
>> > Currently, the instructions[2] say to do the following:
>> > - Download and install an "eid-archive" package, which contains the GPG
>> >   keys and generates a sources.list.d file for the repository;
>> > - Run "apt-get update";
>> > - Install the "eid-mw" and/or "eid-viewer" packages.
>> >
>> > This works, but it has a number of downsides:
>> > - The second step, "run apt-get update", is often overlooked; this seems
>> >   to be the case especially for users of Ubuntu, where the default
>> >   handler for installing packages is the "Software Center", a GUI
>> >   software management tool that doesn't have any UI element for doing
>> >   (the equivalent of) apt-get update
>> > - There is no trust path from your already-installed distribution to the
>> >   "archive" package (yes, I did sign the gpg keys; no, I don't consider
>> >   that enough).
>> > - It still requires users to manually install packages.
>>
>> Given that the packages in question appear to be Free Software (at least
>> from a quick check of a couple of them, as well as the repository being
>> named "main"),
>
> Correct, it's all under GPLv3.
>
>> is there a reason you don't maintain them in Debian
>> (including backports or volatile if you need to provide the newest
>> packages for older distributions)?
>
> As others have pointed out, the said software used to be in Debian (I
> was its maintainer). The reasons for pulling it were long, complicated,
> and boring; suffice to say that there were some practical problems.
>
> (the ftp.d.o bug says "no reply from maintainer", which is only half the
> story. At the time I was aware of issues starting to build around beid,
> and trying to figure out how to fix them; I should've probably replied,
> but it occurred to me that pulling was probably a good strategy, at
> least in the short term)
>
>> If that's not an option for some reason, then given that the packages
>> are Free Software and of reasonably broad interest, you could at least
>> upload a package to Debian containing the archive key, similar to
>> pkg-mozilla-archive-keyring; that would establish a trust path.  (Which
>> doesn't solve the usability problem, but it does solve the trust
>> problem.)
>
> True, but I don't think it is the best way forward.
>
> First, it would work for me, as long as I'm still contracting for the
> government[1]. However, due to it being a *government* contract, this is
> an inherently time-limited situation[2]. I want this situation to remain
> manageable after the end of my contract.
I think this situation still allows maintaining the packages in
Debian, when (if ever) your contract ends and you don't want to
maintain the packages in your free time you can orphan the packages.
The next maintainer could adopt the packages then.

I think this is simple, doable and does not require building trust
with external repositories which I think is not a great idea
generally.

Cheers,
Balint


-- 
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/CAK0OdpwrryX4DJhAK9=0TrRmxRx8RwE4WmQR4kbGXD1hrT1c=q...@mail.gmail.com

Re: Facilitating external repositories

[Josh Triplett]

On Sun, Jun 07, 2015 at 11:08:36AM +0200, Wouter Verhelst wrote:
> On Fri, Jun 05, 2015 at 09:10:56AM -0700, Josh Triplett wrote:
> > If that's not an option for some reason, then given that the packages
> > are Free Software and of reasonably broad interest, you could at least
> > upload a package to Debian containing the archive key, similar to
> > pkg-mozilla-archive-keyring; that would establish a trust path.  (Which
> > doesn't solve the usability problem, but it does solve the trust
> > problem.)
> 
> True, but I don't think it is the best way forward.
> 
> First, it would work for me, as long as I'm still contracting for the
> government[1]. However, due to it being a *government* contract, this is
> an inherently time-limited situation[2]. I want this situation to remain
> manageable after the end of my contract.
> 
> Second, while I wrote this in response to an immediate issue that I'm
> dealing with, it should obvious that this isn't a problem specific to my
> situation; I would prefer to have a situation which works for everyone,
> not just for me. Having to maintain a package inside Debian isn't the
> best solution for third-party developers.

If you don't mind the solution being specific to Debian developers,
though not to you in particular, then the future plans for Debian PPAs
or similar should help here.  In particular, those should inherently
have a trust chain from the archive.

And anything *not* specific to Debian developers shouldn't be automatic;
if there's a means of signing something such that it is "trusted", that
mechanism *must* be limited to DDs.

- Josh Triplett


-- 
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/20150607183001.GA31028@x

Re: Upstream and packaging

[Cyril Brulebois]

Geert Stappers  (2015-06-07):
> What about creating a guide line where upstream creates a directory
> Packaging where sub directories are like Debian, Ubuntu, Mint,
> Redhat, CentOS, Suse and such?
> 
> So Upstream can ship their tar-balls / git repositories with
> the package stuff ( Spec files, debian/ directories ) allready available.
> Next distro have that way a starting point for their packaging.
> 
> My reason for such guide line is that I'm now bitten by our policy
> that upstream should NOT include a debian directory in the top directory
> and there is allready done packaging.
> 
> Does such a guide line allready exist?

There's this guide which you can easily find, searching for “debian
upstream guide”: https://wiki.debian.org/UpstreamGuide

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Facilitating external repositories

[Wouter Verhelst]

On Sun, Jun 07, 2015 at 07:43:30PM +0200, Bálint Réczey wrote:
> I think this situation still allows maintaining the packages in
> Debian, when (if ever) your contract ends and you don't want to
> maintain the packages in your free time you can orphan the packages.
> The next maintainer could adopt the packages then.

Sure, in theory. There are, however, also a few practical reasons why I
don't want to go down that route (that is, the reasons why I chose to
allow beid be dropped from Debian in 2010 still apply).

> I think this is simple, doable and does not require building trust
> with external repositories which I think is not a great idea
> generally.

I disagree with that latter statement.

That's not to say that these external repositories need to be supported
and/or trusted to the same extent as our own repositories, but that's a
different question.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
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/20150607213155.gf7...@grep.be

Re: Facilitating external repositories

[Wouter Verhelst]

On Sun, Jun 07, 2015 at 11:30:01AM -0700, Josh Triplett wrote:
> On Sun, Jun 07, 2015 at 11:08:36AM +0200, Wouter Verhelst wrote:
> > On Fri, Jun 05, 2015 at 09:10:56AM -0700, Josh Triplett wrote:
> > > If that's not an option for some reason, then given that the packages
> > > are Free Software and of reasonably broad interest, you could at least
> > > upload a package to Debian containing the archive key, similar to
> > > pkg-mozilla-archive-keyring; that would establish a trust path.  (Which
> > > doesn't solve the usability problem, but it does solve the trust
> > > problem.)
> > 
> > True, but I don't think it is the best way forward.
> > 
> > First, it would work for me, as long as I'm still contracting for the
> > government[1]. However, due to it being a *government* contract, this is
> > an inherently time-limited situation[2]. I want this situation to remain
> > manageable after the end of my contract.
> > 
> > Second, while I wrote this in response to an immediate issue that I'm
> > dealing with, it should obvious that this isn't a problem specific to my
> > situation; I would prefer to have a situation which works for everyone,
> > not just for me. Having to maintain a package inside Debian isn't the
> > best solution for third-party developers.
> 
> If you don't mind the solution being specific to Debian developers,
> though not to you in particular, then the future plans for Debian PPAs
> or similar should help here.  In particular, those should inherently
> have a trust chain from the archive.

Sure. They don't exist yet, however.

> And anything *not* specific to Debian developers shouldn't be automatic;
> if there's a means of signing something such that it is "trusted", that
> mechanism *must* be limited to DDs.

Actually, we *already* have cases where stuff can be installed on a
Debian system without apt saying anything about it (and without
requiring manual steps) that involves someone preparing an upload who is
not a DD. It's called a DM.

Do we trust DMs to the same level that we trust DDs? No. Is that fine?
Sure. In the same vein, should we trust third-party repositories to the
same level that we trust DDs, or even DMs? Probably not. But then that's
not what I'm suggesting.

Having said that, I do agree with you that we should not allow just
about anyone to create a repository which will be automatically trusted
by the whole Debian system. Establishing such a trust chain should,
indeed, require some vetting by at least one Debian Developer, so that
malicious packages can be rejected, if needs be.

Perhaps this should even be done on a repeating basis; i.e., it could be
done so that getting a signature on an archive configuration can only be
allowed if it is time-limited (so that after a certain amount of time,
the vetting and signing needs to be re-done).

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
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/20150607215523.gg7...@grep.be

Re: Facilitating external repositories

[Josh Triplett]

On Sun, Jun 07, 2015 at 11:55:23PM +0200, Wouter Verhelst wrote:
> On Sun, Jun 07, 2015 at 11:30:01AM -0700, Josh Triplett wrote:
> > On Sun, Jun 07, 2015 at 11:08:36AM +0200, Wouter Verhelst wrote:
> > > On Fri, Jun 05, 2015 at 09:10:56AM -0700, Josh Triplett wrote:
> > > > If that's not an option for some reason, then given that the packages
> > > > are Free Software and of reasonably broad interest, you could at least
> > > > upload a package to Debian containing the archive key, similar to
> > > > pkg-mozilla-archive-keyring; that would establish a trust path.  (Which
> > > > doesn't solve the usability problem, but it does solve the trust
> > > > problem.)
> > > 
> > > True, but I don't think it is the best way forward.
> > > 
> > > First, it would work for me, as long as I'm still contracting for the
> > > government[1]. However, due to it being a *government* contract, this is
> > > an inherently time-limited situation[2]. I want this situation to remain
> > > manageable after the end of my contract.
> > > 
> > > Second, while I wrote this in response to an immediate issue that I'm
> > > dealing with, it should obvious that this isn't a problem specific to my
> > > situation; I would prefer to have a situation which works for everyone,
> > > not just for me. Having to maintain a package inside Debian isn't the
> > > best solution for third-party developers.
> > 
> > If you don't mind the solution being specific to Debian developers,
> > though not to you in particular, then the future plans for Debian PPAs
> > or similar should help here.  In particular, those should inherently
> > have a trust chain from the archive.
> 
> Sure. They don't exist yet, however.

True, but then, neither does any other possible solution to your
problem.  Among the solutions that don't exist yet, PPAs seem
preferable.

> > And anything *not* specific to Debian developers shouldn't be automatic;
> > if there's a means of signing something such that it is "trusted", that
> > mechanism *must* be limited to DDs.
> 
> Actually, we *already* have cases where stuff can be installed on a
> Debian system without apt saying anything about it (and without
> requiring manual steps) that involves someone preparing an upload who is
> not a DD. It's called a DM.

True, but DMs can only upload specific packages, not entire repositories
full of packages.

> Do we trust DMs to the same level that we trust DDs? No. Is that fine?
> Sure. In the same vein, should we trust third-party repositories to the
> same level that we trust DDs, or even DMs? Probably not. But then that's
> not what I'm suggesting.
> 
> Having said that, I do agree with you that we should not allow just
> about anyone to create a repository which will be automatically trusted
> by the whole Debian system. Establishing such a trust chain should,
> indeed, require some vetting by at least one Debian Developer, so that
> malicious packages can be rejected, if needs be.

If there is an external entity we trust enough to upload arbitrary
package to a repository from which packages will be installed on a
Debian system without prompting, that entity should be a DD, since
that's at least as much trust as we give to DDs.  I don't think it's
acceptable to give an *ongoing* blank check to anyone to upload
arbitrary packages to such a repository without that someone being a DD.

- Josh Triplett


-- 
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/20150607231809.GA801@x