Re: Facilitating external repositories

[Wouter Verhelst]

Hi,

On Sat, Nov 09, 2019 at 07:20:44PM +0200, Wouter Verhelst wrote:
> Hi Timo,
> 
> On Sun, Nov 03, 2019 at 07:33:10PM +0100, Timo Weingärtner wrote:
> > Hallo Wouter Verhelst,
> > 
> > 03.11.19 18:35 Wouter Verhelst:
> > > The software from the package downloads the metadata index and validates
> > > the GPG signature; and if everything checks out, adds configuration to
> > > /etc/apt/sources.list.d and /etc/apt/trusted.gpg.d to enable the
> > > repository.
> > 
> > Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key is 
> > in 
> > there its owner can impersonate the official debian repos for default 
> > setups.¹ 
> > Please use some other path (such as /var/lib/extrepo/keyrings/) for the 
> > keyrings and connect it with "Signed-By:" [1].
> > 
> > I just changed my /etc/apt/sources.list.d/debian.sources to have:
> > Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
> 
> Thanks. I agree that makes sense; I've updated the code as such.

So, that has happened, and I have now also uploaded extrepo[1].

In order for this to acually be useful, I would need a bunch of
repositories to be available through the "extrepo" command.

In order for that to happen, I think the best thing to do (eventually)
would be to have the maintainers of said external repositories to
request for them to be added[2]. We'd then need a vetting procedure and a
set of rules for things to be accepted.

I've created a start for that at
. Any comments?

(as a side note, that repository also contains the metadata of the
repositories which extrepo knows...)

Thanks,

[1] https://ftp-master.debian.org/new/extrepo_0.2.html
[2] For the time being though, I've started creating a set of
repositories. I'll probably add more in the next few days or weeks,
as I encounter repositories that might be interesting to add.
Long-term that is probably not the best idea, but short-term I want
to have some critical mass of packages first...

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Facilitating external repositories

[Wouter Verhelst]

Hi Timo,

On Sun, Nov 03, 2019 at 07:33:10PM +0100, Timo Weingärtner wrote:
> Hallo Wouter Verhelst,
> 
> 03.11.19 18:35 Wouter Verhelst:
> > The software from the package downloads the metadata index and validates
> > the GPG signature; and if everything checks out, adds configuration to
> > /etc/apt/sources.list.d and /etc/apt/trusted.gpg.d to enable the
> > repository.
> 
> Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key is in 
> there its owner can impersonate the official debian repos for default 
> setups.¹ 
> Please use some other path (such as /var/lib/extrepo/keyrings/) for the 
> keyrings and connect it with "Signed-By:" [1].
> 
> I just changed my /etc/apt/sources.list.d/debian.sources to have:
> Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Thanks. I agree that makes sense; I've updated the code as such.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Facilitating external repositories

[Paul Wise]

On Mon, Nov 4, 2019 at 4:44 PM Ansgar  wrote:

> I would recommend against doing this as long as sources.list is a
> configuration file: it would need regular updates to change to the new
> signing key.  That doesn't work out of the box.

No updates are needed if you use what Timo suggested:

> I just changed my /etc/apt/sources.list.d/debian.sources to have:
> Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Facilitating external repositories

[Ansgar]

Paul Wise writes:
> On Mon, Nov 4, 2019 at 4:52 AM Guillem Jover  wrote:
>
>> The official archive-keyring packages that use these, I think it's mostly
>> for backwards compatibility reasons.
>
> I wonder if it is feasible to and how the debian-archive-keyring could
> migrate from /etc/apt/trusted.gpg.d/ to /usr/share/keyrings/ +
> signed-by. Right now it ships keyrings in both places.

I would recommend against doing this as long as sources.list is a
configuration file: it would need regular updates to change to the new
signing key.  That doesn't work out of the box.

Ansgar

Re: Facilitating external repositories

[Paul Wise]

On Mon, Nov 4, 2019 at 4:52 AM Guillem Jover  wrote:

> The official archive-keyring packages that use these, I think it's mostly
> for backwards compatibility reasons.

I wonder if it is feasible to and how the debian-archive-keyring could
migrate from /etc/apt/trusted.gpg.d/ to /usr/share/keyrings/ +
signed-by. Right now it ships keyrings in both places.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Facilitating external repositories

[Guillem Jover]

On Sun, 2019-11-03 at 11:04:01 -0800, Russ Allbery wrote:
> Timo Weingärtner  writes:
> > Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key
> > is in there its owner can impersonate the official debian repos for
> > default setups.¹ Please use some other path (such as
> > /var/lib/extrepo/keyrings/) for the keyrings and connect it with
> > "Signed-By:" [1].
> 
> > I just changed my /etc/apt/sources.list.d/debian.sources to have:
> > Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
> 
> I have a personal repository and a corresponding eyrie-archive-keyring
> package to install the trusted keys.  Is there a best practice document
> somewhere for how I should set this up?

I don't think there is. The closest seems to be
, which is not
covering acrhive-keyring packages. Personally I think I've been
picking up this things from following closely apt's development and
having to deal with a couple of these archive-keyring packages.

> I'm currently installing keyrings
> in /etc/apt/trusted.gpg.d because I thought that was how *-archive-keyring
> packages were supposed to work, but this area seems a bit underdocumented
> (or at least I've not found the right documentation).

The official archive-keyring packages that use these, I think it's mostly
for backwards compatibility reasons.

I'd say best practice is to ship keyrings under /usr/share/keyrings/,
and not under /etc/apt/trusted.gpg.d/. Split the keys into keyrings
that will not give more access than necessary. Use «Signed-By:» if you
ship source list files. And personally I ship those in deb822 format,
because they are easier to read and deal with automatically, and make
it easy to disable them after the fact, or even ship them disabled by
default with the «Enabled: no» field.

Thanks,
Guillem

Re: Facilitating external repositories

[Russ Allbery]

Timo Weingärtner  writes:

> Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key
> is in there its owner can impersonate the official debian repos for
> default setups.¹ Please use some other path (such as
> /var/lib/extrepo/keyrings/) for the keyrings and connect it with
> "Signed-By:" [1].

> I just changed my /etc/apt/sources.list.d/debian.sources to have:
> Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

I have a personal repository and a corresponding eyrie-archive-keyring
package to install the trusted keys.  Is there a best practice document
somewhere for how I should set this up?  I'm currently installing keyrings
in /etc/apt/trusted.gpg.d because I thought that was how *-archive-keyring
packages were supposed to work, but this area seems a bit underdocumented
(or at least I've not found the right documentation).

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

Re: Facilitating external repositories

[Timo Weingärtner]

Hallo Wouter Verhelst,

03.11.19 18:35 Wouter Verhelst:
> The software from the package downloads the metadata index and validates
> the GPG signature; and if everything checks out, adds configuration to
> /etc/apt/sources.list.d and /etc/apt/trusted.gpg.d to enable the
> repository.

Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key is in 
there its owner can impersonate the official debian repos for default setups.¹ 
Please use some other path (such as /var/lib/extrepo/keyrings/) for the 
keyrings and connect it with "Signed-By:" [1].

I just changed my /etc/apt/sources.list.d/debian.sources to have:
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg


Grüße
Timo

¹ there are still other attack vectors as soon as you install a package from 
such a repo
[1] sources.list(5)

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

Re: Facilitating external repositories

[Wouter Verhelst]

So, in 2015 I 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
> - 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.
> 
> 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 library that wants to support multiarch, this approach doesn't
> work.
> 
> There is add-apt-repository, which presumably works, but:
> - It doesn't solve the "trust path" issue for third-party repositories,
>   (except, *maybe*, for PPA's, but that's Ubuntu, not Debian, so doesn't
>   solve my problem)
> - It doesn't remove the "manually install" requirement
> - I don't believe it solves the "user didn't do the apt-get update"
>   step, although I haven't checked in detail.
> 
> Do we have anything better, or should I try to come up with something
> myself?
> 
> [1] specifically, https://files.eid.belgum.be/
> [2] http://eid.belgium.be/en/using_your_eid/installing_the_eid_software/linux/

This caused a bit of discussion at the time, but no real implementation. Until
now.

I spent some time earlier this week to write, as a proof-of-concept,
, which contains two repositories:

- The first contains an "extrepo" package, that hasn't been uploaded yet
  (and will probably need some more work before that can happen)
- The "extrepo-data" repository contains some YAML files that can be
  consumed by the first package.

The idea would be that maintainers of third-party repositories (or other
interested parties) can file a merge request to add metadata for their
repository to the index file. When, after proper vetting of the
repository in question, the MR is accepted, that metadata then gets
slightly mangled and signed with a GPG key, then published on
pages.debian.net (or somewhere else, if necessary).

The software from the package downloads the metadata index and validates
the GPG signature; and if everything checks out, adds configuration to
/etc/apt/sources.list.d and /etc/apt/trusted.gpg.d to enable the
repository.

(I could also update the "add-apt-repository" program from the
software-properties-common package, and I might do so if this turns out
to be a success; but for a proof-of-concept that seems premature).

Does this seem like a particularly bad idea to anyone?

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Facilitating external repositories

[Alexandre Detiste]

Le vendredi 12 juin 2015, 17:56:04 Wouter Verhelst a écrit :
> On Fri, Jun 12, 2015 at 10:08:35AM +0200, Alexandre Detiste wrote:
> > Le vendredi 12 juin 2015, 00:59:51 Wouter Verhelst a écrit :
> > > On Thu, Jun 11, 2015 at 12:38:29PM +0200, Bálint Réczey wrote:
> > > > I see eid-mw is built on for i386 and amd64, while I assume it would
> > > > build and work perfectly on arm* laptops and computers as well:
> > > > https://files.eid.belgium.be/debian/pool/main/e/eid-mw/
> > > > 
> > > > Cheers,
> > > > Balint
> > 
> > I was curious, so I tried it on Raspbian's "almost-armhf" architecture
> > & it works ! The java applet is a bit slow, but some embedded
> > application would use some other language.
> 
> Good to know. I haven't tried this myself (enough work with other
> things), but it's interesting none the less.
> 
> Did you try running the test suite? If not, try running
> EID_ROBOT_STYLE=manual make check
> in a checkout of the build tree. This should tell you a bit more about
> how well things work ;-)
> 

Hi,

I see there are now armhf packages in the repository \o/

https://files.eid.belgium.be/debian/pool/main/e/eid-mw/

But these doens't work anymore for me (viewer say "can't detect e-ID reader";
even when run as root, same device work on amd64 desktop); will have to dig 
this a bit further.

lsusb list the ACR38 device correctly

> (if you do find a bug, patches are welcome...)

Here I guess ?

https://github.com/Fedict/eid-mw/

An other thing I miss is eid...@packages.debian.org
could this made to work even for the non-official packages
"bikeshed" packages ?

Alexandre

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

Re: Facilitating external repositories

[Guillem Jover]

Hi!

On Mon, 2015-08-17 at 09:53:17 +0200, Wouter Verhelst wrote:
 A repository with a whitelist cannot install packages with names outside
 that whitelist. It should also not be able to have packages with
 Provides: or Replaces: headers outside that whitelist (so you can't ship
 a package that claims to provide libc6). Since you cannot overwrite
 other packages' files without Replaces:, you can't have a Package:
 libbeidlibc6 which contains a file shipped by libc6.

You can use dpkg-divert, or triggers + moving files around from
maintscripts, but the latter would probably be really dodgy. :)

Regards,
Guillem

Re: Facilitating external repositories

[David Kalnischkies]

(heavy-pruning same-mail subthreads)

On Sun, Aug 16, 2015 at 12:06:53PM +, Anthony Towns wrote:
 Here's how you currently setup an external repo as securely as possible:
 
  1. You hear about a cool repo from somewhere, and are told to go to
 https://example.org/debian/README.html for more instructions.
 
  2. You read that page, and obtain a line to add to sources.list and
 a key to add to apt-key.
 
  3. You (maybe) look at the key to see if it's signed by someone you
 know, and doesn't look shady.
 
  4. You add the key and sources.list entry, and run apt to install the
 packages.
 
 If https and example.org are secure, or if you are able to verify the
 key using the web of trust, this is fine (although it requires a bit of
 effort). 
 
 If neither of those are reliable (because you've got a Lenovo laptop
 so anyone can fake SSL on you or just because its an http:// url not an
 https:// one; and because you don't understand gpg so don't know about
 the web of trust, or because someone in the Debian keyring isn't 100%
 perfect, eg), then there's a MITM attack: I capture your traffic to
 example.org, replace the README, key and repo, and you're stuck.
 
 That's the MITM attack that's avoidable.

So, the solution is to replace key and sources.list entry in the README
with uid on extrepo.d.o: That is a user interface improvement, but
just as attackable as before by the same MITM.

The user interface improvement might be worth it anyhow, but selling
this as huge security improvement is just wrong, which is all I am
against.


 With extrepos as I describe them, the steps are:
 
  1. You hear about a cool repo from somewhere, and are told to just
 get the example-abc123 repo.

  2. You run extrepo add example-abc123, and run apt to install the
 packages.

That should ideally still include 3. as especially with a centralized
site you are susceptible to end up with bad data stored under a similar
name, like you do if you trust short keyids for gpg.


No it isn't fine to have e.g
deb http://httpredir.debian.org/debian sid main
deb http://httpredir.debian.org/debian sid main contrib
If you drop the 'main' from the second (or just the complete first) line
everything is fine.
   It seems fine even with the dupe to me? With:
   deb http://http.debian.net/debian/ testing main contrib non-free
   deb http://http.debian.net/debian/ testing main
   I just get:
   W: Duplicate sources.list entry http://http.debian.net/debian/ 
   testing/main amd64 Packages 
   (/var/lib/apt/lists/http.debian.net_debian_dists_testing_main_binary-amd64_Packages)
  Sure, if you not consider warnings from your package manager a problem,
  then yes, this is totally fine… with the same reasoning we could ignore
  security alltogether as this is just a warning, too, through.
 
 Huh? apt showing a warning doesn't introduce a security problem. Ignoring
 security altogether does.
 
 Oh my, introducing a new repo that duplicates an existing repo gives
 me a warning that I have duplicated repos!!1! just doesn't seem like
 a compelling complaint to me.

That wasn't an all engines full stop. My initial comment on this was you
will *eventually* need to deal with merging in the funky gui tools adding
sources. (highlight by me). And for the record, I think it is really
really bad to even suggest that it is okay to ignore warnings. They are
displayed for a reason – in that case there is a fair chance the user
meant to configure another source but actually didn't.


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Re: Facilitating external repositories

[Anthony Towns]

On Mon, Aug 17, 2015 at 11:15:08AM +0200, David Kalnischkies wrote:
 On Sun, Aug 16, 2015 at 12:06:53PM +, Anthony Towns wrote:
 The user interface improvement might be worth it anyhow, but selling
 this as huge security improvement is just wrong, which is all I am
 against.

I think it's a practical security improvement -- having one point you
can exploit is a lot better than having four points you can exploit. 

But the desired use case is still grab stuff from someone on the Internet
that I don't know well and give it root permissions on my system,
and I don't think you can make that secure in any absolute sense.

If there's any further improvements possible, I can't think of them. :(

  With extrepos as I describe them, the steps are:
   1. You hear about a cool repo from somewhere, and are told to just
  get the example-abc123 repo.
   2. You run extrepo add example-abc123, and run apt to install the
  packages.

[3. check sigs on the key]

 That should ideally still include 3. as especially with a centralized
 site you are susceptible to end up with bad data stored under a similar
 name, like you do if you trust short keyids for gpg.

Sure. In fact, why should extrepo add display that? Is there a web
service that can work out trust paths...?

 That wasn't an all engines full stop. My initial comment on this was you
 will *eventually* need to deal with merging in the funky gui tools adding
 sources. (highlight by me).  

Ah, right -- I definitely read that as all engines full stop. My bad.

 And for the record, I think it is really
 really bad to even suggest that it is okay to ignore warnings. They are
 displayed for a reason – in that case there is a fair chance the user
 meant to configure another source but actually didn't.

Yes, in real use, definitely. I've been kindof focussing on an absolute
minimum viable solution. There are another few bits I've been handwaving
over too for the record:

 - updating a repo (if it needs a new key or new url) is impossible
   as far as I've described

 - there's no way to relate repos (jessie vs wheezy base; stable vs
   dev versions; canonical site vs mirror)

 - providing a search function on extrepos.debian.net might be actively
   /harmful/ for security (ie, it'd be hard to avoid malicious repo
   creators being more effective at SEO on extrepos.d.n than legit
   repo creators)

But (as I said to David in person) seems like it's time to have some code
to throw stones at, rather than just list posts now...

Cheers,
aj

Re: Facilitating external repositories

[Wouter Verhelst]

Hi,

On Wed, Aug 12, 2015 at 08:37:49PM +0200, David Kalnischkies wrote:
 (now that I was ping'ed in reallife… lets finish this draft and make the
 discussion even longer as my previous mail was obviously not long enough
 ;) – or ignore the rambling entirely and skip to the last paragraph )

The joys of Debconf :-)

[...]
 On Tue, Jul 28, 2015 at 12:41:45AM +0200, Wouter Verhelst wrote:
  On Sat, Jul 25, 2015 at 07:27:21PM +0200, David Kalnischkies wrote:
   On Thu, Jul 23, 2015 at 10:14:21AM +0200, Wouter Verhelst wrote:
   and b) the update state of this
   package: The package can happily contain revoked/expired keys (if
   everyone follows the 2 years expire recommendation every key will be
   expired well before the end of security support – not even mentioning
   LTS and apt can't just --refresh-keys as it can't verify the result).
   No longer DDs.  Will not include new DDs. Same for DMs were the active
   state can vary faster based on the ping.
  
  That part is true enough. Not sure how to fix that.
  
  (we could possibly update against Debian's pgp keyserver, but that would
  probably overload that server)
 
 --refresh-keys / --recv-keys can't be used on apts keyring if you aren't
 going to carefully check the result with your eyeballs (and the web of
 trust), aka: an absolute no-go for automation.

Right.

 So whereever you get the keyring updates from, it must be over a secure
 channel like via packages which (at least in the best cases) have
 overload, [long] replay attacks and co sorted out as a bonus, too. Just
 that this requires the package to be a very volatile data package, which
 it currently isn't.

agreed, so perhaps having a central signing key for external repository
configuration files is a better idea.

   There is of course the general problem of if a signature by
   DD actually assures anything.
  
  Well, I do think that if people have gone through the NM process,
  they're generally capable of figuring out whether a package (or a
  package repository) is going to cause problems. The signature a DD would
 
 d-mentors@ is a very lonely place if Debian has indeed ~1000 capable
 reviewers and I would argue that reviewing a single source package is
 less of an investment than reviewing an entire repository, especially
 given that…
 
 
  make in this context is simply a vetting of the packages in this
  repository seem legitimate enough to not do anything that would break
  your system outright.
 
 … your review comes with the repository-equivalent of DM-Upload-Allowed
 attached given that the repository content can change any minute.

True (which is the whole point of this proposal)

  Oh, and given that I got you to sign my example.org repo for me, does
  that mean you are endorsing my endeavor? I mean, pornview is a normal
  image viewer, hotbabe a good cpu monitor and sex my preferred input
  method (as a text editor). Any objections?
 
  Why would there be objections to that? My signature would solely be
  about the technical quality of the packages, not about moral
  implications.
 
 If you say so, but shouldn't that apply to d-mentors@ as well?

There is a huge difference between here's a package with a horrible name for
the Debian archive and here's a repository, external to the Debian archive,
with some stuff with horrible names you might want to install

 My feeling as an observer is that this isn't always the case.
 
 And by extension: Some gpg-users (including DDs) want to get to know me
 before signing my key given that I could be the human equivalent of
 hotbabe they don't want to be associated with…

That's perfectly fine, I don't want to force anyone to do anything.

   Sure, you are basically automating what is currently done by hand by
   many users, but as long as they do it by hand its their own fault
   – if you automate it to one-click they will rightly expect it to be
   secure.
  
  Are you saying we should stick to the current (completely insecure) way
  of tell people to copy-and-paste random shell snippets from the web
  because doing some minimal vetting and signing is not going to give them
  the same level of security they get from installing stuff from the
  Debian archive, and therefore not worth it?
  
  I think that's making the perfect be the enemy of the good.
 
 You can call it like that if you want, but I would say that I am trying
 to be devils advocate here to see if you have responses for the
 'obvious' holes and gaps.
 
 Or in other words:
 
  Sure, packages installed through my proposed scheme would carry less
  trust with them; indeed, they are a more interesting target for a
  blackhat than is the Debian archive. But my proposed scheme *is* an
  improvement to today's situation.
 
 There is no less trust. There is either a I trust you full so I give
 you root rights on my system or I don't trust you and therefore we are
 done here.

This is obviously wrong.

There is a do I trust you enough to give you root on my system. But it
is not 

Re: Facilitating external repositories

[Anthony Towns]

On Sat, Aug 15, 2015 at 12:47:42PM +0200, David Kalnischkies wrote:
  I think my working assumption is anyone can register, and it's done
  automatically. If you want to ensure the URL is owned by the register,
  you could use a dummy DNS record (please add
 extrepo-de684554ae0c3440.example.org CNAME extrepos.debian.net.
  to your DNS).
 Srsly? Until now it sounded very open, but DNS records are far from
 being available for everyone (and far from being secured) beside that
 there can be multiple archives on the same domain. Try again.

Like I said, my working assumption is anyone can register and it's done
automatically, ie no check at all. You wanted something harder, not me :)

A less obstruse check would be:

 - is the nominated key the signing key for the repo's Release file?
 - can the person sign an extrepo request with that signing key?

which should be about sufficient to demonstrate control of the domain
and key.

  Or did you mean that the DD signs the sources.list file directly? 
  Well,
  then my key isn't usable for that right now, but in exchange the DD
  might have a slight problem in assuring the correctness of what he 
  is
  signing: I am the owner of example.org/debian. Trust me.
I'm not sure this is a problem -- if you're not the owner of
example.org/debian, then the files I download from there won't have your
signature. If they do have your signature, then it's just the question
of whether I trust your random repo, and I can't figure that out just
from knowing who you are.
   … I was thinking man-in-the-middle here. If I can register
   example.org/debian with a key of my choosing I can do really bad things,
   especially if example.org is the domain of a Debian mirror and I manage
   to trick people into adding this e.g. by claiming that this is a faster
   mirror…
 […]
  If you put in a /different/ key and go to the trouble of intercepting
  some users' traffic to example.org, things look slightly different:
 […]
  There's a few problems with doing that:
   a) anybody whose traffic to example.org you can't intercept will
  get an error if they check that repo against the nominated signing key.
  if extrepos.d.n does minimal sanity checking before adding a repo,
  this makes this attack a non-starter afaics.
 So, let me get this straight: The reason we need extrepo.d.o is because
 there could be an all consuming man-in-the-middle exchanging the
 description as well as the download of the archive key with something of
 his own choosing, but if we have extrepo.d.o this is suddently no longer
 a problem because it is too unlikely that there is such a man-in-the-
 middle.

Obviously not.

Here's how you currently setup an external repo as securely as possible:

 1. You hear about a cool repo from somewhere, and are told to go to
https://example.org/debian/README.html for more instructions.

 2. You read that page, and obtain a line to add to sources.list and
a key to add to apt-key.

 3. You (maybe) look at the key to see if it's signed by someone you
know, and doesn't look shady.

 4. You add the key and sources.list entry, and run apt to install the
packages.

If https and example.org are secure, or if you are able to verify the
key using the web of trust, this is fine (although it requires a bit of
effort). 

If neither of those are reliable (because you've got a Lenovo laptop
so anyone can fake SSL on you or just because its an http:// url not an
https:// one; and because you don't understand gpg so don't know about
the web of trust, or because someone in the Debian keyring isn't 100%
perfect, eg), then there's a MITM attack: I capture your traffic to
example.org, replace the README, key and repo, and you're stuck.

That's the MITM attack that's avoidable.

There's an entirly separate attack that's fundamental to external repos:
I make an external repo of my own, pretend that it's good, get people
to install from it, but actually upload bad things into it. In that case
I'm not in the middle though, I'm an endpoint.

With extrepos as I describe them, the steps are:

 1. You hear about a cool repo from somewhere, and are told to just
get the example-abc123 repo.

 2. You run extrepo add example-abc123, and run apt to install the
packages.

extrepo uses a Debian signed certificate linking example-abc123 to a
unique key and url, so that anyone who tries to get that repo is pointing
to the same place.

If you want to tell people to go to a different repo -- example-123abc
say, that's fine; but allowing that is a required feature. Likewise,
you could MITM the forums that are raving about what a great repo
example-abc123 is, and make them look like they're raving about
example-123abc, but I don't think that's avoidable.

   b) if someone's trying to install a PPA for secured-ssh, why would
   they go through extrepos?
 Because editing sources.list is hard and running 'extrepo add
 ppa-whatever-16734' is 

Re: Facilitating external repositories

[David Kalnischkies]

On Thu, Aug 13, 2015 at 05:46:24PM +, Anthony Towns wrote:
 On Thu, Aug 13, 2015 at 11:23:19AM +0200, David Kalnischkies wrote:
  On Wed, Aug 12, 2015 at 11:12:05PM +, Anthony Towns wrote:
   To use an external repo, you need a deb822 sources.list file and a pubkey.
   
   To get those, you contact extrepos.debian.net, and either do some sort
   of search, or plug in a 6+ digit hex code. extrepos.debian.net spits
   back a signed bundle of the repo's public key and a deb822 sources.list
   (which includes a description of what the repo is meant to contain), both
   named to match the 6+ digit hex code.
  That could work (see also below), you just need to figure out a way of
  registering an external repository at extrepos.debian.org now, which
  involves deciding who can register one and how to ensure that what
  I register is actually owned by me because…
 
 I think my working assumption is anyone can register, and it's done
 automatically. If you want to ensure the URL is owned by the register,
 you could use a dummy DNS record (please add
extrepo-de684554ae0c3440.example.org CNAME extrepos.debian.net.
 to your DNS).

Srsly? Until now it sounded very open, but DNS records are far from
being available for everyone (and far from being secured) beside that
there can be multiple archives on the same domain. Try again.


 Or did you mean that the DD signs the sources.list file directly? 
 Well,
 then my key isn't usable for that right now, but in exchange the DD
 might have a slight problem in assuring the correctness of what he is
 signing: I am the owner of example.org/debian. Trust me.
   I'm not sure this is a problem -- if you're not the owner of
   example.org/debian, then the files I download from there won't have your
   signature. If they do have your signature, then it's just the question
   of whether I trust your random repo, and I can't figure that out just
   from knowing who you are.
  … I was thinking man-in-the-middle here. If I can register
  example.org/debian with a key of my choosing I can do really bad things,
  especially if example.org is the domain of a Debian mirror and I manage
  to trick people into adding this e.g. by claiming that this is a faster
  mirror…
[…]
 If you put in a /different/ key and go to the trouble of intercepting
 some users' traffic to example.org, things look slightly different:
[…]
 There's a few problems with doing that:
 
  a) anybody whose traffic to example.org you can't intercept will
 get an error if they check that repo against the nominated signing key.
 if extrepos.d.n does minimal sanity checking before adding a repo,
 this makes this attack a non-starter afaics.

So, let me get this straight: The reason we need extrepo.d.o is because
there could be an all consuming man-in-the-middle exchanging the
description as well as the download of the archive key with something of
his own choosing, but if we have extrepo.d.o this is suddently no longer
a problem because it is too unlikely that there is such a man-in-the-
middle.


  b) if someone's trying to install a PPA for secured-ssh, why would
  they go through extrepos?

Because editing sources.list is hard and running 'extrepo add
ppa-whatever-16734' is easy? -- How many people have changed their used
Debian mirror to the DebConf local one. How many would have if I had
posted a extrepo snipped which would do it with just one click?

Or just because the PPAs are signed by the Debians archive keyring
doesn't mean they shouldn't be served by extrepo.d.o as they are
external repositories, just that they have an established trustpath
already – would be bad to have a system to look for packages of (newer
versions of) foobar in external repos which ignores PPAs which might as
well be the best source for it…


  c) if you've gotten someone to install your extrepo, and they'll agree to
 install things signed by your key, why not just point them directly
 at a server you control? if you do that, you can be much nastier,
 eg by serving a real secured ssh to most people, and a vulnerable
 ssh only to people you're trying to hack.

 Running an extrepo by someone you don't trust at all is still crazy,
 as installing software written by someone you don't trust at all is crazy.
 The improvement is for the case where:
 
  - you trust Debian
  - you trust whoever wrote/packaged the software by reputation
  - you don't have direct communication with the software author/packager,
or their public key, etc

Which is exactly the problem. You have moved the problem of being unable
to establish a trust path from user to archive, to extrepo to archive
– which is potentially a better place to get a path – but yet you have
completely omitted how the trustpath is established and just declared
that extrepo does it somehow while this is the most important part.

So again, lets say I am registering example.org/debian as repository
with key 0xABCDEF, how do you ensure 

Re: Facilitating external repositories

[David Kalnischkies]

On Wed, Aug 12, 2015 at 11:12:05PM +, Anthony Towns wrote:
 I'm not sure if the idea is PPAs can only be added to by DDs/DMs. If
 not, can anonymous folks setup a PPA for pirated software, or try to
 compromise the PPA build system or similar? If PPAs are for DDs and DMs
 only, I'm presuming they can just use the existing Debian keyring to sign
 the PPA Release files.

There is a session about Debian PPAs at 2015-08-21 17:00..18:00
@ DebConf, so all the details there I presume, but as far as public
information up to today goes (which I have seen) is that they are
limited to DD/DM, on Debian infrastructure and signed by the usual
archive signing key, so that trust in the archive-key isn't an issue
here – the problem is just in easily adding PPAs to your sources which
while currently bundled in this thread as well, I would like to avoid as
a topic for now to focus on the archive-key part for external archives
which aren't signed by Debian.


- Apt will try to download it from a default location in the repository
  (or perhaps a location specified in the deb822 sources.list file
  itself).
   What the heck is it in this sentence? I envision deb822 sources.list
   file, but reading the location of the file from the file itself seems
   a bit hard to pull of in practice…
  I was thinking of having apt auto-update the file which is put there, so
  that if something changes (e.g., new signatures), we pick that up.
 
 To use an external repo, you need a deb822 sources.list file and a pubkey.
 
 To get those, you contact extrepos.debian.net, and either do some sort
 of search, or plug in a 6+ digit hex code. extrepos.debian.net spits
 back a signed bundle of the repo's public key and a deb822 sources.list
 (which includes a description of what the repo is meant to contain), both
 named to match the 6+ digit hex code.

That could work (see also below), you just need to figure out a way of
registering an external repository at extrepos.debian.org now, which
involves deciding who can register one and how to ensure that what
I register is actually owned by me because…

   Or did you mean that the DD signs the sources.list file directly? Well,
   then my key isn't usable for that right now, but in exchange the DD
   might have a slight problem in assuring the correctness of what he is
   signing: I am the owner of example.org/debian. Trust me.
 
 I'm not sure this is a problem -- if you're not the owner of
 example.org/debian, then the files I download from there won't have your
 signature. If they do have your signature, then it's just the question
 of whether I trust your random repo, and I can't figure that out just
 from knowing who you are.

… I was thinking man-in-the-middle here. If I can register
example.org/debian with a key of my choosing I can do really bad things,
especially if example.org is the domain of a Debian mirror and I manage
to trick people into adding this e.g. by claiming that this is a faster
mirror…

Which isn't much different to how a man-in-the-middle works nowadays on
the installation of an archive-keyring by man-in-the-middle the site
where the instructions are written down to add the sources.list entry
and the key.

SSL CAs regularily mess up checking that I am really the owner of
example.org I want to get a certificate for and extrepos.d.o would be
basically a certificate authority, just not for SSL but for
archive-keys.


   If you are adding archive signing keys it must be hundred percent bullet
   proof or all of apt-secure is broken. 
 
 So you probably want to be able to say this key is only valid for this
 deb/deb-src url before doing any of this. Is that possible already? I'm
 guessing not.

You will be able in apt 1.1 as noted somewhere deep down in this thread.
See git for details:
https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=b0d408547734100bf86781615f546487ecf390d9
https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=4e03c47de15164f2656d9655edab6fb3570cb2f2

So, what you might want to do is drop the archive key somewhere which
is not /etc/apt/trusted.gpg.d/ and declare with this option where this
keyring file is. Maintain this keyring in a -archive-keyring package and
you can do key transitions easily. Maintain this package not in the
third-party repository but in an extrepos.debian.org archive just
containing -archive-keyring packages and you can do 'revokes' of keys by
no longer including it in the package, which gives you the 'ping' to the
extrepos.d.o service for free in a secure way as otherwise we had to
figure out a way to sign the ping, ensure it isn't a replay attack and
all that stuff more or less solved for packages.


   Sure, you are basically automating what is currently done by hand by
   many users, but as long as they do it by hand its their own fault – if
   you automate it to one-click they will rightly expect it to be secure.
 
 That's a fair enough view. I look at it more as users will do whatever
 works. if we can provide a way 

Re: Facilitating external repositories

[Anthony Towns]

On Thu, Aug 13, 2015 at 11:23:19AM +0200, David Kalnischkies wrote:
 On Wed, Aug 12, 2015 at 11:12:05PM +, Anthony Towns wrote:
  I'm not sure if the idea is PPAs can only be added to by DDs/DMs. [...]
 There is a session about Debian PPAs at 2015-08-21 17:00..18:00
 @ DebConf, so all the details there I presume, but as far as public
 information up to today goes (which I have seen) is that they are
 limited to DD/DM, on Debian infrastructure and signed by the usual
 archive signing key, so that trust in the archive-key isn't an issue
 here – the problem is just in easily adding PPAs to your sources which
 while currently bundled in this thread as well, I would like to avoid as
 a topic for now to focus on the archive-key part for external archives
 which aren't signed by Debian.

Yeah, that mostly sounds straightforward -- apt key is already fine,
uploads and new repos don't add much more risk than unstable already has,
everything in PPAs goes to a central server and can be tracked so it's
not easy to use PPAs to sneak things onto individual systems.

The downside is it limits things to DDs/DMs, so it doesn't make it much
easier to get totally new stuff available for Debian users, so that's
where extrepos come in.

  To use an external repo, you need a deb822 sources.list file and a pubkey.
  
  To get those, you contact extrepos.debian.net, and either do some sort
  of search, or plug in a 6+ digit hex code. extrepos.debian.net spits
  back a signed bundle of the repo's public key and a deb822 sources.list
  (which includes a description of what the repo is meant to contain), both
  named to match the 6+ digit hex code.
 That could work (see also below), you just need to figure out a way of
 registering an external repository at extrepos.debian.org now, which
 involves deciding who can register one and how to ensure that what
 I register is actually owned by me because…

I think my working assumption is anyone can register, and it's done
automatically. If you want to ensure the URL is owned by the register,
you could use a dummy DNS record (please add
   extrepo-de684554ae0c3440.example.org CNAME extrepos.debian.net.
to your DNS).

Or did you mean that the DD signs the sources.list file directly? Well,
then my key isn't usable for that right now, but in exchange the DD
might have a slight problem in assuring the correctness of what he is
signing: I am the owner of example.org/debian. Trust me.
  I'm not sure this is a problem -- if you're not the owner of
  example.org/debian, then the files I download from there won't have your
  signature. If they do have your signature, then it's just the question
  of whether I trust your random repo, and I can't figure that out just
  from knowing who you are.
 … I was thinking man-in-the-middle here. If I can register
 example.org/debian with a key of my choosing I can do really bad things,
 especially if example.org is the domain of a Debian mirror and I manage
 to trick people into adding this e.g. by claiming that this is a faster
 mirror…

I still don't think this is true?

Let's suppose you've found a mirror of a PPA that's intended for building
honeypots, so it has a version of sshd with a bad random number generator
and a couple of known exploits. It's signed by the Debian archive keyring.

Now I create an extrepo as follows:

  Type: deb deb-src
  URI: http://mirror.example.org/debian-ppas/honeypot/
  Suite: stable
  Section: main
  Description: security enhanced sshd
   This repo contains enhaned builds of sshd and some related
   utilities with vastly improved security options over the
   standard builds in Debian.
  Signing-Key:
   [archive signing key goes here]

How is that an advantage over just setting up my own extrepo with
dangerous packages and a misleading description?

If you put in a /different/ key and go to the trouble of intercepting
some users' traffic to example.org, things look slightly different:

  Type: deb deb-src
  URI: http://mirror.example.org/debian-ppas/secured-ssh
  Suite: stable
  Section: main
  Description: security enhanced sshd
   This repo contains enhaned builds of sshd and some related
   utilities with vastly improved security options over the
   standard builds in Debian.
  Signing-Key:
   [*MY* signing key goes here]

There's a few problems with doing that:

 a) anybody whose traffic to example.org you can't intercept will
get an error if they check that repo against the nominated signing key.
if extrepos.d.n does minimal sanity checking before adding a repo,
this makes this attack a non-starter afaics.

 b) if someone's trying to install a PPA for secured-ssh, why would they
go through extrepos?

 c) if you've gotten someone to install your extrepo, and they'll agree to
install things signed by your key, why not just point them directly
at a server you control? if you do that, you can be much nastier,
eg by serving a real secured ssh to most people, and a vulnerable
   

Re: Facilitating external repositories

[Jakub Wilk]

* Anthony Towns a...@erisian.com.au, 2015-08-12, 23:12:

debian-keyring is a 51MB deb, that's pretty big.


FWIW, it could be shrunk to ~10MB if the keys were minimized 
(--export-options export-minimal).


--
Jakub Wilk

Re: Facilitating external repositories

[Jonathan McDowell]

On Thu, Aug 13, 2015 at 07:53:52PM +0200, Jakub Wilk wrote:
 * Anthony Towns a...@erisian.com.au, 2015-08-12, 23:12:
 debian-keyring is a 51MB deb, that's pretty big.
 
 FWIW, it could be shrunk to ~10MB if the keys were minimized
 (--export-options export-minimal).

We recently switched to export-clean to retain only signatures that can
be verified. This brings it down to 26M for debian-keyring.gpg (by far
the largest keyring), while still providing the signatures within the
Debian trust space.

J.

-- 
] http://www.earth.li/~noodles/ [] 101 things you can't have too much  [
]  PGP/GPG Key @ the.earth.li   []  of : 42 - Pepsi.   [
] via keyserver, web or email.  [] [
] RSA: 4096/0x94FA372B2DA8B985  [] [


signature.asc
Description: Digital signature

Re: Facilitating external repositories

[Anthony Towns]

(Piling onto this after a dc15 dinner convo referencing it)

On Tue, Jul 28, 2015 at 12:41:45AM +0200, Wouter Verhelst wrote:
 On Sat, Jul 25, 2015 at 07:27:21PM +0200, David Kalnischkies wrote:
  On Thu, Jul 23, 2015 at 10:14:21AM +0200, Wouter Verhelst wrote:

(apologies if the identity of who's being quoted below is confusing)

So aiui there's three levels of repos we're talking about:

 - Debian controlled: main, contrib, non-free; stable, testing, unstable,
   experimental

 - PPAs: Debian hosted, but more loosely controlled. experimental gone
   wild? maybe third party uploads? probably only free things?

 - External repos: all sorts of random crap.

(I'm not sure where the line between Debian PPAs and external repos is)

As far as trust goes, I think we can (and have to) assume that people
can install Debian safely somehow; and from that point on have access
to a current debian-archive-key as well as the debian-keyring and
debian-maintainers keyrings.

I think the level of trust you would want for PPAs then is probably that
you're able to see a name and description (like rust2.0, this will
give you pre-alpha access to packages of rust as it goes towards 2.0) and
be confident that what you install will match what you expect from that.

I'm not sure what checks will go into putting stuff in PPAs; being Debian
hosted it would be possible to block uploads based on lintian checks,
or limit PPAs to a specific set of packages (so the rust2.0 PPA couldn't
sneak an update to libc6 in), or limit updates that change the Provides:
or Conflicts: headers.

I'm not sure if the idea is PPAs can only be added to by DDs/DMs. If
not, can anonymous folks setup a PPA for pirated software, or try to
compromise the PPA build system or similar? If PPAs are for DDs and DMs
only, I'm presuming they can just use the existing Debian keyring to sign
the PPA Release files.

Anyhoo.

To make external repos both secure and easy, I think you want to do
two things:

 - make sure that it's easy to check that when you're talking about
   Bob's cool custom wordpress debs that you can be sure you don't
   end up at a different repo that your friend uses

 - limit the damage a bad repo can do (particularly by accident, though
   if you can limit malicious repos too, that's a bonus)

To check that a repo is the same, I think you need to have a trusted
party tie some sort of canonical name to a repo description. I think
the canonical name could be a URL or it could be a shortened hash of the
description (like a git commit id); and presumably the trusted third party
would be a debian.org registry service. I kind-of like the hash idea since
that makes it more difficult to repurpose a repo without changing its id.

So I think that adds up to:

   - Apt will try to download it from a default location in the repository
 (or perhaps a location specified in the deb822 sources.list file
 itself).
  What the heck is it in this sentence? I envision deb822 sources.list
  file, but reading the location of the file from the file itself seems
  a bit hard to pull of in practice…
 I was thinking of having apt auto-update the file which is put there, so
 that if something changes (e.g., new signatures), we pick that up.

To use an external repo, you need a deb822 sources.list file and a pubkey.

To get those, you contact extrepos.debian.net, and either do some sort
of search, or plug in a 6+ digit hex code. extrepos.debian.net spits
back a signed bundle of the repo's public key and a deb822 sources.list
(which includes a description of what the repo is meant to contain), both
named to match the 6+ digit hex code.

The user can then edit the sources.list file as desired (choose a
different mirror, set a particular pin priority, ...?)


From the POV of someone maintaining an external repo, all you have to do
beyond making the packages and setting up the Packages files and signing
your work is give it a permanent description and upload the whole thing
to extrepos.d.n which will then generate the 6+ digit hex code identifier,
sign the set of things, and make it available for download.

Updates to the repo work automatically.

Updating the key should be straightforward -- sign the new key with
the old one and upload to extrepos.d.n. Supporting a cold storage
key-signing-key could also work.

You'd presumably want to be able to blacklist repos, in case they're
taken down, their key is compromised, or they're found to be doing
malicious or illegal things. That would mean polling extrepos.d.n,
possibly during apt-get update?

You might want to go further and let users rate repos; but maybe
that could be done externally (eg, on a reddit board or a forum). You
probably wouldn't want listing on extrepos.d.n to be taken as any sort
of endorsement by Debian (or SPI) though.

 I'm not suggesting this be part of the base system. It should be part of
 the desktop task, probably, but that one is large enough already that
 this shouldn't make much of a difference.

Re: Facilitating external repositories

[Vincent Bernat]

 ❦ 12 août 2015 23:12 GMT, Anthony Towns a...@erisian.com.au :

  - PPAs: Debian hosted, but more loosely controlled. experimental gone
wild? maybe third party uploads? probably only free things?

It could also be backports that don't fit the backport policy.
-- 
I have never let my schooling interfere with my education.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Facilitating external repositories

[David Kalnischkies]

(now that I was ping'ed in reallife… lets finish this draft and make the
discussion even longer as my previous mail was obviously not long enough
;) – or ignore the rambling entirely and skip to the last paragraph )

On Tue, Jul 28, 2015 at 12:41:45AM +0200, Wouter Verhelst wrote:
 On Sat, Jul 25, 2015 at 07:27:21PM +0200, David Kalnischkies wrote:
  On Thu, Jul 23, 2015 at 10:14:21AM +0200, Wouter Verhelst wrote:
  and b) the update state of this
  package: The package can happily contain revoked/expired keys (if
  everyone follows the 2 years expire recommendation every key will be
  expired well before the end of security support – not even mentioning
  LTS and apt can't just --refresh-keys as it can't verify the result).
  No longer DDs.  Will not include new DDs. Same for DMs were the active
  state can vary faster based on the ping.
 
 That part is true enough. Not sure how to fix that.
 
 (we could possibly update against Debian's pgp keyserver, but that would
 probably overload that server)

--refresh-keys / --recv-keys can't be used on apts keyring if you aren't
going to carefully check the result with your eyeballs (and the web of
trust), aka: an absolute no-go for automation.

So whereever you get the keyring updates from, it must be over a secure
channel like via packages which (at least in the best cases) have
overload, [long] replay attacks and co sorted out as a bonus, too. Just
that this requires the package to be a very volatile data package, which
it currently isn't.


  There is of course the general problem of if a signature by
  DD actually assures anything.
 
 Well, I do think that if people have gone through the NM process,
 they're generally capable of figuring out whether a package (or a
 package repository) is going to cause problems. The signature a DD would

d-mentors@ is a very lonely place if Debian has indeed ~1000 capable
reviewers and I would argue that reviewing a single source package is
less of an investment than reviewing an entire repository, especially
given that…


 make in this context is simply a vetting of the packages in this
 repository seem legitimate enough to not do anything that would break
 your system outright.

… your review comes with the repository-equivalent of DM-Upload-Allowed
attached given that the repository content can change any minute.


 Oh, and given that I got you to sign my example.org repo for me, does
 that mean you are endorsing my endeavor? I mean, pornview is a normal
 image viewer, hotbabe a good cpu monitor and sex my preferred input
 method (as a text editor). Any objections?

 Why would there be objections to that? My signature would solely be
 about the technical quality of the packages, not about moral
 implications.

If you say so, but shouldn't that apply to d-mentors@ as well?
My feeling as an observer is that this isn't always the case.

And by extension: Some gpg-users (including DDs) want to get to know me
before signing my key given that I could be the human equivalent of
hotbabe they don't want to be associated with…


  Sure, you are basically automating what is currently done by hand by
  many users, but as long as they do it by hand its their own fault
  – if you automate it to one-click they will rightly expect it to be
  secure.
 
 Are you saying we should stick to the current (completely insecure) way
 of tell people to copy-and-paste random shell snippets from the web
 because doing some minimal vetting and signing is not going to give them
 the same level of security they get from installing stuff from the
 Debian archive, and therefore not worth it?
 
 I think that's making the perfect be the enemy of the good.

You can call it like that if you want, but I would say that I am trying
to be devils advocate here to see if you have responses for the
'obvious' holes and gaps.

Or in other words:

 Sure, packages installed through my proposed scheme would carry less
 trust with them; indeed, they are a more interesting target for a
 blackhat than is the Debian archive. But my proposed scheme *is* an
 improvement to today's situation.

There is no less trust. There is either a I trust you full so I give
you root rights on my system or I don't trust you and therefore we are
done here.


 Today, a blackhat who wishes to install a trojan onto a victim's
 just needs to trick said victim into calling 'gdebi' on a .deb file.
 This *works*. It doesn't require *any* signature, and can do as much (or
 even more) harm than with my proposed scheme. This is bad, IMO; I want
 to fix that. I don't think it's a particular hole which we can
 *completely* plug, but we can make it a smaller one. That's what my
 proposal is trying to accomplish.

If your goal is to replace 'one shot' installations of .deb files it
would be better to head for signed deb files – there is quite a bit of
an overhead between a single .deb file and creating an entire repository
around this .deb file. Overhead not everyone wants to work with and/or
is even 

Re: Facilitating external repositories

[Игорь Пашев]

2015-06-05 19:10 GMT+03:00 Josh Triplett j...@joshtriplett.org:
 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), 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)?


It takes ages to pass mentors.debian.net? :-)


-- 
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/CALL-Q8zvSaHgMHJUOPr49Ub3aUCQPYUCKUR32=dh1g6bzmn...@mail.gmail.com

Re: Facilitating external repositories

[Jonas Smedegaard]

Quoting Игорь Пашев (2015-07-28 21:11:57)
 2015-06-05 19:10 GMT+03:00 Josh Triplett j...@joshtriplett.org:
 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), 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)?


 It takes ages to pass mentors.debian.net? :-)

Then maintain the package(s) collaboratively by joining a team.


 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Facilitating external repositories

[Wouter Verhelst]

On Sat, Jul 25, 2015 at 07:27:21PM +0200, David Kalnischkies wrote:
 On Thu, Jul 23, 2015 at 10:14:21AM +0200, Wouter Verhelst wrote:
  - Apt will try to download it from a default location in the repository
(or perhaps a location specified in the deb822 sources.list file
itself).
 
 What the heck is it in this sentence? I envision deb822 sources.list
 file, but reading the location of the file from the file itself seems
 a bit hard to pull of in practice…

I was thinking of having apt auto-update the file which is put there, so
that if something changes (e.g., new signatures), we pick that up.

Obviously it can't place it there by itself initially; that would be the
responsibility of my proposed new tool.

  - It may be GPG-signed by one or more keys. Apt should have a way of
configuring GPG keys that may be allowed to sign sources.list files,
preloaded with the set of keys in the Debian keyring. This will allow
system administrators in large environments to specify their own set
of keys allowed to sign repositories, as well as allowing downstreams
to add its own ways of trusting repositories.
 
 Using the Debian keyring as a preload means a) a big package pushed into
 the default set of installed packages

I'm not suggesting this be part of the base system. It should be part of
the desktop task, probably, but that one is large enough already that
this shouldn't make much of a difference.

 and b) the update state of this
 package: The package can happily contain revoked/expired keys (if
 everyone follows the 2 years expire recommendation every key will be
 expired well before the end of security support – not even mentioning
 LTS and apt can't just --refresh-keys as it can't verify the result).
 No longer DDs.  Will not include new DDs. Same for DMs were the active
 state can vary faster based on the ping.

That part is true enough. Not sure how to fix that.

(we could possibly update against Debian's pgp keyserver, but that would
probably overload that server)

 There is of course the general problem of if a signature by a 'random'
 DD actually assures anything.

Well, I do think that if people have gone through the NM process,
they're generally capable of figuring out whether a package (or a
package repository) is going to cause problems. The signature a DD would
make in this context is simply a vetting of the packages in this
repository seem legitimate enough to not do anything that would break
your system outright.

 I mean, I have a key signed by a few DDs,
 does that mean I can repropose my key now for an archive? Sounds about
 right to me at least. So much for a trusted path from Debian to [your]
 repository as it is now my man-in-the-middled repository.
 (Did I say I repropose? That was the blackhat stealing my key of course)

I'm not sure I can parse this part of your mail.

The idea was:
- A third-party developer wants to create a repository with packages
- A DD checks the repository, sees that the packages are legitimate
  enough
- The DD signs a sources.list file to express that the repository seems
  safe enough.

That does not involve signing *keys*, does it?

 Or did you mean that the DD signs the sources.list file directly? Well,
 then my key isn't usable for that right now, but in exchange the DD
 might have a slight problem in assuring the correctness of what he is
 signing: I am the owner of example.org/debian. Trust me.
 
 If you thought the default CA trust store in a browser is (too) large,
 I am not sure what a 1000+ key trust store would be. Sounds for me like
 the wet dream of security folks (not)…

I proposed that because it doesn't require any setup, and because we
already trust DDs to be able to judge the quality of random packages,
but I suppose we could create a system whereby the set of keys that can
sign is much smaller, and some team/committee/whatever does the vetting,
rather than j random DD.

The downside of such a system is, obviously, that it would require some
extra red tape to work.

 Oh, and given that I got you to sign my example.org repo for me, does
 that mean you are endorsing my endeavor? I mean, pornview is a normal
 image viewer, hotbabe a good cpu monitor and sex my preferred input
 method (as a text editor). Any objections?

Why would there be objections to that? My signature would solely be
about the technical quality of the packages, not about moral
implications.

 And god forbit that I might turn (even more) evil.  Or the person I am
 selling the domain to in three months… (Or should I say the blackhat
 who did a hostile take over of my domain and now ships trojans to
 everyone with a sources.list signed by you).

Right. An obvious missing part in my proposal is that it would require
the ability to revoke signatures somehow.

Not sure how to accomplish that in a way that will scale without killing
a central server or some such.

Will give that some thought.

[...]
 If you are adding archive signing keys it must be hundred 

Re: Facilitating external repositories

[David Kalnischkies]

On Thu, Jul 23, 2015 at 10:14:21AM +0200, Wouter Verhelst wrote:
 - Apt will try to download it from a default location in the repository
   (or perhaps a location specified in the deb822 sources.list file
   itself).

What the heck is it in this sentence? I envision deb822 sources.list
file, but reading the location of the file from the file itself seems
a bit hard to pull of in practice…


 - It may be GPG-signed by one or more keys. Apt should have a way of
   configuring GPG keys that may be allowed to sign sources.list files,
   preloaded with the set of keys in the Debian keyring. This will allow
   system administrators in large environments to specify their own set
   of keys allowed to sign repositories, as well as allowing downstreams
   to add its own ways of trusting repositories.

Using the Debian keyring as a preload means a) a big package pushed into
the default set of installed packages and b) the update state of this
package: The package can happily contain revoked/expired keys (if
everyone follows the 2 years expire recommendation every key will be
expired well before the end of security support – not even mentioning
LTS and apt can't just --refresh-keys as it can't verify the result).
No longer DDs.  Will not include new DDs. Same for DMs were the active
state can vary faster based on the ping.

There is of course the general problem of if a signature by a 'random'
DD actually assures anything. I mean, I have a key signed by a few DDs,
does that mean I can repropose my key now for an archive? Sounds about
right to me at least. So much for a trusted path from Debian to [your]
repository as it is now my man-in-the-middled repository.
(Did I say I repropose? That was the blackhat stealing my key of course)

Or did you mean that the DD signs the sources.list file directly? Well,
then my key isn't usable for that right now, but in exchange the DD
might have a slight problem in assuring the correctness of what he is
signing: I am the owner of example.org/debian. Trust me.

If you thought the default CA trust store in a browser is (too) large,
I am not sure what a 1000+ key trust store would be. Sounds for me like
the wet dream of security folks (not)…


Oh, and given that I got you to sign my example.org repo for me, does
that mean you are endorsing my endeavor? I mean, pornview is a normal
image viewer, hotbabe a good cpu monitor and sex my preferred input
method (as a text editor). Any objections? And god forbit that I might
turn (even more) evil.  Or the person I am selling the domain to in
three months… (Or should I say the blackhat who did a hostile take over
of my domain and now ships trojans to everyone with a sources.list
signed by you). But yeah, you are not endorsing me, you just signed
a document to give me root access on every machine you happen to be
a trusted signer on – that is totally different.


Some of this is a problem for an archive signing key as well, but the
difference is that an archive signing key is signing a Release file
which regularly changes, but a sources.list file hardly changes. It
especially doesn't change in the last example with a domain takeover and
there is no poor man's repository version of the web of trust.


If you are adding archive signing keys it must be hundred percent bullet
proof or all of apt-secure is broken. Sure, you are basically automating
what is currently done by hand by many users, but as long as they do it
by hand its their own fault – if you automate it to one-click they will
rightly expect it to be secure.


 - It may possibly add a limitation on the packages that can be
   downloaded from the given repository (so that a package repository
   cannot suddenly acquire a package libc6, accidentally or otherwise).
   This should allow for wildcards (e.g., in my specific situation this
   field would contain libbeid*, eid-*, beid-*)

While a nice feature, hardly a security one as for an attacker it is
only important to know which package to infect. libc6 is of course
installed by everyone, so an upgrade in a bugged repository has the
desired effect, but any person with your repository active will also
have one of your packages installed – otherwise they wouldn't have the
repository in the first place, right – so that feature gives a warm
fuzzy feeling at best. Who cares in the end if the package I run my evil
maintainer script with is called 'libc6' or 'eid' …

btw: Who is controlling that whitelist? Lets imagine that your tool
needs in version 2 two new obscure libraries: You will have a hard time
convincing John Doe that he should update the list by hand after apt-get
crapped out with an error message saying that much – on the other hand
Jane Doe will be disappointed if you let apt-get change the list based
on the wishes of the repository. And lets face it: Nobody will be happy
if apt-get is asking a question about this as everyone will be trained
to press 'yes' pretty quickly.

Oh, and what about eid-libc6 provides+replaces libc6 ? 

Re: Facilitating external repositories

[Guillem Jover]

Hi!

On Sat, 2015-07-25 at 11:10:25 +0800, Paul Wise wrote:
 I would suggest reviewing Ubuntu's solution for adding PPA sources.list
 snippets and seeing if we can take any inspiration from it or make our
 solution more compatible with it.
 
 https://help.ubuntu.com/community/Repositories/Ubuntu#Adding_PPAs
 
 I'm not aware of any other solutions from derivative distros, but you
 might want to contact the debian-derivatives list to find out.

Maemo's Hildon Application Manager did have support for one-click
installs of packages and repository information:

  http://hildon-app-mgr.garage.maemo.org/install-devel.html

Thanks,
Guillem


-- 
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/20150725040021.gb9...@gaara.hadrons.org

Re: Facilitating external repositories

[Paul Wise]

On Thu, 2015-07-23 at 10:14 +0200, Wouter Verhelst wrote:

 Thoughts?

Looks good to me.

This will be more useful once the Debian PPA idea is implemented.

Where does the name of the file in /etc/apt/sources.list.d/ come from?

I would suggest reviewing Ubuntu's solution for adding PPA sources.list
snippets and seeing if we can take any inspiration from it or make our
solution more compatible with it.

https://help.ubuntu.com/community/Repositories/Ubuntu#Adding_PPAs

I'm not aware of any other solutions from derivative distros, but you
might want to contact the debian-derivatives list to find out.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Re: Facilitating external repositories

[Ian Jackson]

Wouter Verhelst writes (Re: Facilitating external repositories):
 On Thu, Jul 23, 2015 at 01:03:15PM +0100, Ian Jackson wrote:
  The /name/ of the external repository should also be covered by the
  signature.
 
 What would you describe as the name of the repository?
 
 The URL is already part of the sources.list file. Additionally, the
 deb822 form of the sources.list file is already configured to have a
 short and long Description: field.

Ah, I think the short and long Description are probably the answer.  I
wasn't aware of that.

I was thinking that tools would want to show something to the user.  A
Description is probably the right thing and if it is covered by the
signature then great.

 Am I missing something?

I think probably I was.  (Also I may be missing something now, too - I
have just got back from the pub...)

Ian.


-- 
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/21937.28150.812508.153...@chiark.greenend.org.uk

Re: Facilitating external repositories

[Ian Jackson]

Wouter Verhelst writes (Re: Facilitating external repositories):
 - It may be GPG-signed by one or more keys. Apt should have a way of
   configuring GPG keys that may be allowed to sign sources.list files,
   preloaded with the set of keys in the Debian keyring. This will allow
   system administrators in large environments to specify their own set
   of keys allowed to sign repositories, as well as allowing downstreams
   to add its own ways of trusting repositories.

The /name/ of the external repository should also be covered by the
signature.

Ian.


-- 
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/21936.55299.724772.736...@chiark.greenend.org.uk

Re: Facilitating external repositories

[Wouter Verhelst]

On Thu, Jul 23, 2015 at 01:03:15PM +0100, Ian Jackson wrote:
 Wouter Verhelst writes (Re: Facilitating external repositories):
  - It may be GPG-signed by one or more keys. Apt should have a way of
configuring GPG keys that may be allowed to sign sources.list files,
preloaded with the set of keys in the Debian keyring. This will allow
system administrators in large environments to specify their own set
of keys allowed to sign repositories, as well as allowing downstreams
to add its own ways of trusting repositories.
 
 The /name/ of the external repository should also be covered by the
 signature.

What would you describe as the name of the repository?

The URL is already part of the sources.list file. Additionally, the deb822 form
of the sources.list file is already configured to have a short and long
Description: field.

Am I missing something?

-- 
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/20150723173947.gb2...@grep.be

Re: Facilitating external repositories

[Wouter Verhelst]

So, 

I've been giving this some more thought, and have tried to write a spec, but
then found that...

On Sat, Jun 13, 2015 at 05:03:15PM +0800, Paul Wise wrote:
 https://lists.debian.org/deity/2014/01/msg00055.html

...this (and the discussion following it) actually seems fairly close to
what my spec was going to be.

I would suggest that the deb822 sources.list format be slightly
extended so that:

- Apt will try to download it from a default location in the repository
  (or perhaps a location specified in the deb822 sources.list file
  itself).
- It may be GPG-signed by one or more keys. Apt should have a way of
  configuring GPG keys that may be allowed to sign sources.list files,
  preloaded with the set of keys in the Debian keyring. This will allow
  system administrators in large environments to specify their own set
  of keys allowed to sign repositories, as well as allowing downstreams
  to add its own ways of trusting repositories.
- It may possibly add a limitation on the packages that can be
  downloaded from the given repository (so that a package repository
  cannot suddenly acquire a package libc6, accidentally or otherwise).
  This should allow for wildcards (e.g., in my specific situation this
  field would contain libbeid*, eid-*, beid-*)
- (It would be good if apt also added the ability to limit keys on a
  per-repository basis, already suggested in the January 2014 discussion
  but not yet implemented due to missing required infrastructure)

We could then also add a field Default-Install:, ignored by apt but
honoured by a handler for the MIME type of sources.list files, that
would list a set of packages to install by default when adding this
repository.

Added together, this would give maintainers of third-party repositories
the following:
- A trusted path from Debian to their repository;
- Insurance (when the sources.list file is signed by multiple keys)
  against a DD leaving the project, or their key being compromised, or
  similar;
- A way for their users to install the software they're using by
  clicking on a link (to the sources.list file, passed on to this MIME
  type handler) which automatically (after appropriate authentication
  and confirmation) adds the file to sources.list, runs apt-get
  update, and installs a default set of packages from this repository.

At the same time, it would allow us to limit the possible damage
third-party repositories can do in several ways:
- Limit the keys with which they can sign their repositories;
- Limit the packages they can override, very much in the same way we
  limit DMs today;
- If the Pin-Priority: field as proposed by aj is implemented (doesn't
  appear to be the case today), limit the impact the repository can
  have.

Of course, the above may or may not be appropriate in some cases, so I'm
not suggesting we make any of those fields mandatory; it should be up to
the DD signing the sources.list configuration file to ensure that the
contents of that file is sane and safe.

Thoughts?

-- 
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 13, 2015 at 10:48:35AM +0800, Paul Wise wrote:
 On Fri, Jun 12, 2015 at 11:47 PM, Wouter Verhelst wrote:
 
  For the latter, it is usually possible to supply a link to a .repo
  file; for all of those distributions, tools exist to automagically
  configure the system so that the repository is enabled and the gpg key
  is added as a trusted key (after appropriate confirmation from the
  user).
 
 Porting this stuff to Debian sounds like the right thing to do? Do you
 have any technical details about how that works?

It's different for every distribution, but basically the .repo file is
also what you store in their repository configuration (i.e., it's the
same file format). That means it can't really be done the same way for
us; a .repo file also contains information about which gpg key can be
used for that repository, but our sources.list file (or sources.list.d
snippets) doesn't contain that information.

Basically, it's download, ask confirmation, store in right location
for them; and since yum and zypper and friends don't need the equivalent
of apt-get update, that just works. It won't for us (in that form),
though.

-- 
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/20150613065149.ga7...@grep.be

Re: Facilitating external repositories

[Tollef Fog Heen]

]] Wouter Verhelst 

 On Mon, Jun 08, 2015 at 09:12:51AM +0200, Tollef Fog Heen wrote:
  ]] Wouter Verhelst 
  
   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.
  
  I've always been a bit unhappy about the idea of using keys to decide
  which repositories are trusted or not.  The signature is there primarily
  to act as an anti-MITM tool.  This is a bit similar (or maybe
  equivalent) to the difference between authentication and authorization
  for access control.
 
 What would you suggest instead?

With our current setup?  I don't really know, I think we'd need to add
some more information to some files.

Currently, there's no binding between an apt repository as listed in
sources.list and the corresponding key.  There is also no link between
an apt repository and allowed packages from that repository.

I could see us extending the apt preferences format to be something
like:

Package: *
Origin: Debian
Allowed-Keys: 2B90D010, C857C906, 518E17E1

Package: foo
Origin: fooCorp
Allowed-Keys: ABCD, EF12, 1234

Default priority for an unlisted package is  0 (so can't be
installed).  We should probably use fingerprints and not short key ids
for the allowed-keys field (and we need something to manage them when
doing dist-upgrades and such).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m2381wypoi@rahvafeir.err.no

Re: Facilitating external repositories

[Tollef Fog Heen]

]] Paul Wise 

 On Sat, Jun 13, 2015 at 4:31 PM, Tollef Fog Heen wrote:
 
  I could see us extending the apt preferences format to be something
  like:
 
 Why the preferences file instead of the sources.list file, which can
 already be in deb822 format?

Primarily because I wasn't aware of that format, and secondly the exact
implementation of where the information goes isn't core to my
suggestion.  The point is to tie apt repository, allowed packages and
expected key(s) together in a single place.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m2wpz8x8m7@rahvafeir.err.no

Re: Facilitating external repositories

[Paul Wise]

On Sat, Jun 13, 2015 at 4:31 PM, Tollef Fog Heen wrote:

 I could see us extending the apt preferences format to be something
 like:

Why the preferences file instead of the sources.list file, which can
already be in deb822 format?

https://lists.debian.org/deity/2014/01/msg00055.html

Some more hardening we could do along with the key thing:

https://lists.debian.org/deity/2014/02/msg00017.html

-- 
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/CAKTje6GXX3GjHhre1KPza8M-O516BHPJZyR4s1m7DdO=xlx...@mail.gmail.com

Re: Facilitating external repositories

[Alexandre Detiste]

Le vendredi 12 juin 2015, 00:59:51 Wouter Verhelst a écrit :
 On Thu, Jun 11, 2015 at 12:38:29PM +0200, Bálint Réczey wrote:
  I see eid-mw is built on for i386 and amd64, while I assume it would
  build and work perfectly on arm* laptops and computers as well:
  https://files.eid.belgium.be/debian/pool/main/e/eid-mw/
  
  Cheers,
  Balint

I was curious, so I tried it on Raspbian's almost-armhf architecture
 it works ! The java applet is a bit slow, but some embedded
application would use some other language.

Having an armhf package in a Debian unnofficial repo
means that it must still be recompiled for Raspbian
because there armhf means something else.

(or the armhf package could be build in a way that
amrv7 instructions are allways avoided, or a separate
repos is built only for Raspbian)

The eid-viewer is now an 'any' package, but couldn't it be an 'all'
because it only include a java program, an icon  a .desktop file?

Alexandre Detiste


--
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/1793536.pIiYa9OGHR@antec

Re: Facilitating external repositories

[Bálint Réczey]

Hi Wouter,

2015-06-12 0:59 GMT+02:00 Wouter Verhelst wou...@debian.org:
 On Thu, Jun 11, 2015 at 12:38:29PM +0200, Bálint Réczey wrote:
 Hi Wouter,

 2015-06-07 23:31 GMT+02:00 Wouter Verhelst w...@uter.be:
  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 have reread the thread twice but I could not find details of the
 practical reasons.

 That would be because they're not mentioned there :-)

 Could you please share them? A link would be enough if I just missed it.

 - I don't want to have to deal with doing a maven build in a Debian
   package. If you see what the packages' debian/rules do, ou'll see that
   we cheat for eid-viewer.
This does not sound like building a binary we could trust.

 - The packages exist mostly to support cards that have a limited
   validity. When they're no longer valid, you return the old one and get
   a new one. Sometimes, it happens that the newer cards have a bug, or
   have a new feature, or some such, which means that the old version of
   the software doesn't really work anymore, and you need a new one.
   Having older versions in the archive for years after they stop working
   turned out to be a support nightmare for upstream.
I think with wheezy-backports the situation improved a lot. The application
could check if *-backports is enabled and warn the user if it is not. You could
keep updated versions in *-backports, thus avoiding the nightmare.

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/CAK0Odpw3o+o_Y06v=umnqa1vgabee8oxvhcoqo_7jv395zn...@mail.gmail.com

Re: Facilitating external repositories

[Paul Wise]

On Fri, Jun 12, 2015 at 11:47 PM, Wouter Verhelst wrote:

 For the latter, it is usually possible to supply a link to a .repo
 file; for all of those distributions, tools exist to automagically
 configure the system so that the repository is enabled and the gpg key
 is added as a trusted key (after appropriate confirmation from the
 user).

Porting this stuff to Debian sounds like the right thing to do? Do you
have any technical details about how that works?

-- 
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/CAKTje6GS3tyeDLusRmmmv+=+przdfg5vethqdkew8rsd0+t...@mail.gmail.com

Re: Facilitating external repositories

[Wouter Verhelst]

On Fri, Jun 12, 2015 at 10:08:35AM +0200, Alexandre Detiste wrote:
 Le vendredi 12 juin 2015, 00:59:51 Wouter Verhelst a écrit :
  On Thu, Jun 11, 2015 at 12:38:29PM +0200, Bálint Réczey wrote:
   I see eid-mw is built on for i386 and amd64, while I assume it would
   build and work perfectly on arm* laptops and computers as well:
   https://files.eid.belgium.be/debian/pool/main/e/eid-mw/
   
   Cheers,
   Balint
 
 I was curious, so I tried it on Raspbian's almost-armhf architecture
  it works ! The java applet is a bit slow, but some embedded
 application would use some other language.

Good to know. I haven't tried this myself (enough work with other
things), but it's interesting none the less.

Did you try running the test suite? If not, try running
EID_ROBOT_STYLE=manual make check
in a checkout of the build tree. This should tell you a bit more about
how well things work ;-)

(if you do find a bug, patches are welcome...)

[...]
 The eid-viewer is now an 'any' package, but couldn't it be an 'all'
 because it only include a java program, an icon  a .desktop file?

Yeah. It probably should; it's been on my TODO list for a while to fix
this, but I haven't yet had the time to look at it in detail. It's not
like it makes things break, and so it's not very high priority...

-- 
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/20150612155604.gd5...@grep.be

Re: Facilitating external repositories

[Wouter Verhelst]

Hi Bálint,

On Fri, Jun 12, 2015 at 11:19:30AM +0200, Bálint Réczey wrote:
 Hi Wouter,
 
 2015-06-12 0:59 GMT+02:00 Wouter Verhelst wou...@debian.org:
 
  - I don't want to have to deal with doing a maven build in a Debian
package. If you see what the packages' debian/rules do, ou'll see that
we cheat for eid-viewer.

 This does not sound like building a binary we could trust.

It isn't appropriate for inclusion in Debian, that much I agree with. It
should be trustworthy, though.

  - The packages exist mostly to support cards that have a limited
validity. When they're no longer valid, you return the old one and get
a new one. Sometimes, it happens that the newer cards have a bug, or
have a new feature, or some such, which means that the old version of
the software doesn't really work anymore, and you need a new one.
Having older versions in the archive for years after they stop working
turned out to be a support nightmare for upstream.
 I think with wheezy-backports the situation improved a lot. The application
 could check if *-backports is enabled and warn the user if it is not. You 
 could
 keep updated versions in *-backports, thus avoiding the nightmare.

This is true, to some extent, but it does not solve all my problems.

We also support Ubuntu and Linux Mint, not to speak of the set of
RPM-based distributions for which there are packages.

For the latter, it is usually possible to supply a link to a .repo
file; for all of those distributions, tools exist to automagically
configure the system so that the repository is enabled and the gpg key
is added as a trusted key (after appropriate confirmation from the
user).

The same is not true for Debian, and I think this should be the case.
I believe the answer to how do I make a proper third-party repository
should *not* be don't.

What I'm trying to fix here is not something that will help me in the
short term; indeed, due to the remaining length of the contract and the
average length of a Debian release cycle, it is even possible that this
won't help me anymore but will only be useful for whoever it is that
will succeed me.

I could start uploading to backports today, and create a PPA for ubuntu,
and continue to maintain third-party repositories for fedora, centos,
and opensuse. But that would mean I have to upload packages to three
different places. It would also mean that the workflow for providing the
results of my continuous integration builds would be significantly
different from the results of the regular builds. This would all be
undesirable.

To clarify: the reason that I mailed to -devel was not please help me
fix my problem; instead, I did so because I believe there is a gap in
our current support for third-party repositories, and because I believe
this is a problem that needs fixing. Taking away my personal need for
maintaining third-party repositories, while interesting in and of
itself, does not actually do that; the gap would still exist for other
people.

Taking away the need for third-party repositories in the first place
*would* help fix that, yes. By creating PPA's, improving backports
support, and other similar things, it is true that the need for
third-party repositories will diminish; but I don't think it will ever
go away completely, and so it makes sense to improve support for such
repositories.

Regards,

-- 
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

[Bálint Réczey]

Hi Wouter,

2015-06-07 23:31 GMT+02:00 Wouter Verhelst w...@uter.be:
 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 have reread the thread twice but I could not find details of the
practical reasons.
Could you please share them? A link would be enough if I just missed it.

I for example maintain a repository for kodi for for more than a half
year because it sits in the NEW queue and I can't tell how happy I
would be if I could stop building it for amd64, i386 and mipsel (which
is really slow) again and again and I also have to tell armhf users to
wait for official builds because I don't have the HW to build it.

I see eid-mw is built on for i386 and amd64, while I assume it would
build and work perfectly on arm* laptops and computers as well:
https://files.eid.belgium.be/debian/pool/main/e/eid-mw/

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/CAK0Odpx8uSd=bjbpqyaytsm3vjmm4uj3tzhx3mftpndu1cw...@mail.gmail.com

Re: Facilitating external repositories

[Wouter Verhelst]

On Thu, Jun 11, 2015 at 12:38:29PM +0200, Bálint Réczey wrote:
 Hi Wouter,
 
 2015-06-07 23:31 GMT+02:00 Wouter Verhelst w...@uter.be:
  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 have reread the thread twice but I could not find details of the
 practical reasons.

That would be because they're not mentioned there :-)

 Could you please share them? A link would be enough if I just missed it.

- I don't want to have to deal with doing a maven build in a Debian
  package. If you see what the packages' debian/rules do, ou'll see that
  we cheat for eid-viewer.
- The packages exist mostly to support cards that have a limited
  validity. When they're no longer valid, you return the old one and get
  a new one. Sometimes, it happens that the newer cards have a bug, or
  have a new feature, or some such, which means that the old version of
  the software doesn't really work anymore, and you need a new one.
  Having older versions in the archive for years after they stop working
  turned out to be a support nightmare for upstream.

 I for example maintain a repository for kodi for for more than a half
 year because it sits in the NEW queue and I can't tell how happy I
 would be if I could stop building it for amd64, i386 and mipsel (which
 is really slow) again and again and I also have to tell armhf users to
 wait for official builds because I don't have the HW to build it.
 
 I see eid-mw is built on for i386 and amd64, while I assume it would
 build and work perfectly on arm* laptops and computers as well:
 https://files.eid.belgium.be/debian/pool/main/e/eid-mw/
 
 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/CAK0Odpx8uSd=bjbpqyaytsm3vjmm4uj3tzhx3mftpndu1cw...@mail.gmail.com
 
 

-- 
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/20150611225951.ga18...@grep.be

Re: Facilitating external repositories

[Wouter Verhelst]

On Mon, Jun 08, 2015 at 09:12:51AM +0200, Tollef Fog Heen wrote:
 ]] Wouter Verhelst 
 
  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.
 
 I've always been a bit unhappy about the idea of using keys to decide
 which repositories are trusted or not.  The signature is there primarily
 to act as an anti-MITM tool.  This is a bit similar (or maybe
 equivalent) to the difference between authentication and authorization
 for access control.

What would you suggest instead?

-- 
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/20150609165225.ga5...@grep.be

Re: Facilitating external repositories

[Tollef Fog Heen]

]] Wouter Verhelst 

 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.

I've always been a bit unhappy about the idea of using keys to decide
which repositories are trusted or not.  The signature is there primarily
to act as an anti-MITM tool.  This is a bit similar (or maybe
equivalent) to the difference between authentication and authorization
for access control.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87sia2isgc@xoog.err.no

Re: Facilitating external repositories

[Dimitri John Ledkov]

On 4 June 2015 at 17:18, Wouter Verhelst wou...@debian.org wrote:
 - Run apt-get update;
 - Install the eid-mw and/or eid-viewer packages.

These two steps can be accomplished with a single APT URL, e.g.:

a href=apt:pkg?refresh=yepinstall pkg/a

which will refresh and install request package(s). Ubuntu's software
centre is the default handler for apt: urls, and I believe there are
other software packages also provide similar functionality.

I don't believe there is an apt-url scheme to add a repository with a
GPG key, but it would be very cool. Or, e.g. for apt repositories to
become discoverable in general similar to how e.g. coreos/rkt URL
discovery works to find containers and their gpg signatures derived
from simple urls.

Regards,

Dimitri.


-- 
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/canbhluir0_kvtj2krhlh+wrivn1uhjbsb-p7r6dwbeagoyn...@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: Facilitating external repositories

[Bálint Réczey]

Hi Wouter,

2015-06-07 11:08 GMT+02:00 Wouter Verhelst wou...@debian.org:
 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

[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

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

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 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 library that wants to support multiarch, this approach doesn't
  work.
 
 And 

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

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

[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

Re: Facilitating external repositories

[Vincent Bernat]

 ❦  6 juin 2015 13:48 +0800, Paul Wise p...@debian.org :

 the software is far to volatile (e.g. important bug fixes on a weekly basis)

 We have a place for such software: experimental

Won't work for users needing the software on a stable release.
-- 
Use recursive procedures for recursively-defined data structures.
- The Elements of Programming Style (Kernighan  Plauger)


signature.asc
Description: PGP signature

Re: Facilitating external repositories

[Alexandre Detiste]

Le samedi 6 juin 2015, 00:13:59 Brian May a écrit :
 On Sat, 6 Jun 2015 at 02:11 Josh Triplett j...@joshtriplett.org wrote:
 
  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), 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)?
 

Well, this had been in Debian for some years until 2010
under an other name: 'beid'
https://packages.qa.debian.org/b/beid.html
but I don't know why it was removed.

 In my case I maintain open source software Debian packages outside of
 Debian because the software is far to volatile (e.g. important bug fixes on
 a weekly basis) and I don't want old versions hanging around any longer
 then absolutely required.

Maybe Debian could just ship eid-archive package almost as-is,
it's not like the key changes every day;
the one active here doesn't even have an expiry date.

This only contain:
  /usr/share/eid-archive/eid.list
  /usr/share/eid-archive/keys/10a04d46.gpg
  /usr/share/eid-archive/keys/6773d225.gpg - Belgian eID Automatic Signing Key 
(official releases)
 + a postinst  postrm

The others packages would remain in  http://files.eid.belgium.be/debian/

There is very little to clean-up:

lintian 
/var/cache/apt-cacher-ng/files.eid.belgium.be/debian/pool/main/e/eid-archive/eid-archive_2014.8_all.deb
W: eid-archive: copyright-without-copyright-notice
W: eid-archive: command-with-path-in-maintainer-script postrm:7 /usr/bin/ucf

 It is also a very narrow market, possibly not of
 general interest to the Debian community (this is hard to determine
 however; maybe what this needs right now is expanded exposure).

Well 'beid' was there before and a there's a potential 10 millions
persons having to do their taxes this month and needing this
stuff if they are using Debian or a derivative.

eid-archive is a tiny 'all' package that weights 6040 bytes :-)
I guess the pros outweigh the cons.

 There was also the (slightly confusing) perception in management that they
 had to tightly control ownership and distribution, despite it being open
 source GPL software, available on github, etc.

Entirely possible :-(

Alexandre Detiste





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

Re: Facilitating external repositories

[Adam Borowski]

On Sat, Jun 06, 2015 at 09:47:01AM +0200, Alexandre Detiste wrote:
 Well, this had been in Debian for some years until 2010
 under an other name: 'beid'
 https://packages.qa.debian.org/b/beid.html
 but I don't know why it was removed.

The reason is in the RM bug (#672784):
RM: beid -- RoQA; RC-buggy; no maintainer responses


-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
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/20150606213722.ga7...@angband.pl

Re: Facilitating external repositories

[Chris Knadle]

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.

 - 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?  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.  As the debian-keyring package would come from the
main archive, that would at least have a trust path to the signing key
of the main distribution repository.

That's what I can think of at the moment anyway.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us


-- 
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/5573bf41.8040...@coredump.us

Re: Facilitating external repositories

[Josh Triplett]

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), 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)?

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.)

I don't think you can have a dpkg trigger run apt update, since dpkg
will typically be invoked under the apt lock.  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 library that wants to support multiarch, this approach doesn't
 work.

And presumably factoring that out into a common package that other
packages depend on won't help, because then you don't have a single
installable package, so you go back to needing a repository.

 [1] specifically, https://files.eid.belgum.be/

Did you mean https://files.eid.belgium.be/  Because the URL you posted
doesn't work with https, and the http version looks shady.

- 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/20150605161051.GA1471@jtriplet-mobl1

Re: Facilitating external repositories

[Osamu Aoki]

Hi,

On Thu, Jun 04, 2015 at 06:18:16PM +0200, Wouter Verhelst wrote:
 Hi,
 
...
 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.
 
...
 
 There is add-apt-repository, which presumably works, but:
 - It doesn't solve the trust path issue for third-party repositories,
   (except, *maybe*, for PPA's, but that's Ubuntu, not Debian, so doesn't
   solve my problem)
 - It doesn't remove the manually install requirement
 - I don't believe it solves the user didn't do the apt-get update
   step, although I haven't checked in detail.

The add-apt-repository command is from the softwareproperties-common
package.  It has associated GUI packages.
 softwareproperties-kde
 softwareproperties-gtk

These allow you to import key manually and add repository.

I did not check for the manual addition of repository source case, but
when I added and removed the non-free archive via GUI, the apt-cache
...  result changed indicating the GUI program run apt-get update
equivalent in the background.

I did not check if installation of key has dialogue for verifying its
authenticity... if not, adding such functionality may be what you need.

Osamu


-- 
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/20150605231303.GA31034@goofy.local

Re: Facilitating external repositories

[Brian May]

On Sat, 6 Jun 2015 at 02:11 Josh Triplett j...@joshtriplett.org wrote:

 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), 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)?


In my case I maintain open source software Debian packages outside of
Debian because the software is far to volatile (e.g. important bug fixes on
a weekly basis) and I don't want old versions hanging around any longer
then absolutely required. It is also a very narrow market, possibly not of
general interest to the Debian community (this is hard to determine
however; maybe what this needs right now is expanded exposure).

There was also the (slightly confusing) perception in management that they
had to tightly control ownership and distribution, despite it being open
source GPL software, available on github, etc.

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.

Re: Facilitating external repositories

[Paul Wise]

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

. It is also a very narrow market, possibly not of
 general interest to the Debian community (this is hard to determine however;
 maybe what this needs right now is expanded exposure).

We have a lot of obscure software in Debian already, the size of the
audience shouldn't matter.

 There was also the (slightly confusing) perception in management that they
 had to tightly control ownership and distribution, despite it being open
 source GPL software, available on github, etc.

We probably shouldn't distribute it if upstream doesn't want us to though.

 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.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
http://bonedaddy.net/pabs3/
http://wiki.openmoko.org/wiki/User: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/caktje6gw_fsko464vsqyncn_5bopn6o5m2u7fdwvj4p+scq...@mail.gmail.com