Re: Developer repositories for Debian
On Mon, May 11, 2015 at 3:12 PM, Leopold Palomo-Avellaneda wrote: At least DM. I expect DMs will have access (as the mail talks about the uploading keyring*s*). I do not understand how lintian can do a complete check without binaries. It can't check binaries if they don't get uploaded and lintian certainly can never be considered a complete check, even if it does check the binaries. Probably the most important is build-time testing using upstream test suites. Next up is package install, upgrade and removal testing with piuparts. http://piuparts.debian.org/ Also important is as-installed package testing with DEP-8, autopkgtest and debci: http://dep.debian.net/deps/dep8/ http://packages.debian.org/sid/autopkgtest http://ci.debian.net/ There is also static analysis, fuzzing, manual review and so on: https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package [buildds] only for DD... and DMs. -- 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/CAKTje6FVEK-A7QaQ4bq67koUGe0OJEdbpfwiK=+fuj_ayvk...@mail.gmail.com
Re: Developer repositories for Debian
El Dilluns, 11 de maig de 2015, a les 11:52:13, Paul Wise va escriure: On Sun, May 10, 2015 at 11:48 PM, Leopold Palomo-Avellaneda wrote: people.d.o AFAIK is _only_ for DD. Anyway, if I can see it correctly it's only web space. My ppa propose could be also useful for Debian members. I think that new packages, are controller by ftp-masters, so any help to create a new package could be welcome. I think you may have misunderstood the proposal that this thread is about. The proposal was not for a PPA system like on Launchpad where any member of the public can register an account and immediately upload packages. The access policy for the proposed Debian PPA system was to be exactly the same as for the rest of the Debian archive; only accessible by uploading Debian members (aka DDs), others need to go through a sponsor. In that sense, it is almost exactly the same as people.d.o or *.debian.net. https://lists.debian.org/87y5btehw3@gkar.ganneff.de I misunderstood the proposal but after read the complete history I agree in general. It looks like it's a very cool project. If the creation of pps could be a more open that not _only_ DD, to me is perfect. At least DM. One interesting thing of mentors is that the packages are checked by lintian, so you need some binary ... You definitely do not need to upload binaries to mentors. I do not understand how lintian can do a complete check without binaries. For instance is a package is empty or not, or if you have installed a binary without manpage, or the sonames are correct or not. But probably I have misunderstood something in the thread. [...] I cannot understand why you have this opposition. They idea is that the project could offer the option to build packages for Debian. We already have that: https://buildd.debian.org/ https://db.debian.org/machines.cgi I'm not sure how/if the PPA proposal will use these machines though. only for DD... that you could say that, then you will have a lot of packages, maybe without quality, and you don't want the make a relation between that packages and the official ones. But, this is another thing. Indeed. Not only non-x86. I work _only_ with amd64 arch. In theory, it should not be necessary to have another pbuild environment for 32 bit: they are quite identical. However, I can say that we suffered in one bug of our packages because, in 32 bits, sometimes FTBFS because an strange combination of memory and parallel compilation. And, we were three persons involved in that package: two uploaders and one sponsor. Sounds like an interesting bug :) For building on i386 I'd just use pbuilder and or qemu. If people would like to be able to build/test on other arches before uploading to Debian, there are some options already: Debian members can login to Debian porterboxen and run builds/tests/etc in various chroots: https://db.debian.org/machines.cgi Debian contributors can get guest accounts on the Debian porterboxen and do the same: https://dsa.debian.org/doc/guest-account/ Very interesting. Thanks for the info. Anyone can buy or solicit donations of hardware and build/test on those. Anyone can use the existing services (LAVA, GCC, OpenPOWER and cloud providers). https://wiki.debian.org/Hardware/Wanted Thanks. Well, now just wait to see. Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? signature.asc Description: This is a digitally signed message part.
Re: Developer repositories for Debian
On Sat, May 09, 2015 at 09:23:26AM +0200, Mechtilde wrote: Hello Am 05.05.2015 um 23:45 schrieb Mike Hommey: On Sun, May 05, 2013 at 02:22:04PM +0200, Joerg Jaspert wrote: Hello world, Now with wheezy happy and out the door, we should finally tackle a long open issue. Developer repositories (AKA PPA) for Debian. Now with jessie happy and out the door, what is the status of Developer repositories for Debian? Why can't you use people.debian.org for this? I'm not interested by the hosting part, it's not a problem. The problem is building packages for multiple debian architectures. At some point I might get annoyed enough with the current state of affairs that I'll build my own fake buildd network on debian machines, now that we (DDs) can install arbitrary packages in the schroots. But then, I'm not sure other people will like that the e.g. mips and arm developer machines are spending most of their time building iceweasel. Mike -- 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/20150511085255.ga8...@glandium.org
Re: Developer repositories for Debian
On Sun, May 10, 2015 at 11:48 PM, Leopold Palomo-Avellaneda wrote: people.d.o AFAIK is _only_ for DD. Anyway, if I can see it correctly it's only web space. My ppa propose could be also useful for Debian members. I think that new packages, are controller by ftp-masters, so any help to create a new package could be welcome. I think you may have misunderstood the proposal that this thread is about. The proposal was not for a PPA system like on Launchpad where any member of the public can register an account and immediately upload packages. The access policy for the proposed Debian PPA system was to be exactly the same as for the rest of the Debian archive; only accessible by uploading Debian members (aka DDs), others need to go through a sponsor. In that sense, it is almost exactly the same as people.d.o or *.debian.net. https://lists.debian.org/87y5btehw3@gkar.ganneff.de One interesting thing of mentors is that the packages are checked by lintian, so you need some binary ... You definitely do not need to upload binaries to mentors. many times is better that someone more test it, because some more eyes could found more problems. Also, different environments could help to find strange incompatibilities. Agreed. Many people don't have website and don't want to maintain a website. ...not all the people have this kind services. This is true, most people use Facebook as their website these days, which doesn't support uploading arbitrary files in a directory structure. Surely technical people who are contributing to Debian probably have access to a way to do this though? I cannot understand why you have this opposition. They idea is that the project could offer the option to build packages for Debian. We already have that: https://buildd.debian.org/ https://db.debian.org/machines.cgi I'm not sure how/if the PPA proposal will use these machines though. that you could say that, then you will have a lot of packages, maybe without quality, and you don't want the make a relation between that packages and the official ones. But, this is another thing. Indeed. Not only non-x86. I work _only_ with amd64 arch. In theory, it should not be necessary to have another pbuild environment for 32 bit: they are quite identical. However, I can say that we suffered in one bug of our packages because, in 32 bits, sometimes FTBFS because an strange combination of memory and parallel compilation. And, we were three persons involved in that package: two uploaders and one sponsor. Sounds like an interesting bug :) For building on i386 I'd just use pbuilder and or qemu. If people would like to be able to build/test on other arches before uploading to Debian, there are some options already: Debian members can login to Debian porterboxen and run builds/tests/etc in various chroots: https://db.debian.org/machines.cgi Debian contributors can get guest accounts on the Debian porterboxen and do the same: https://dsa.debian.org/doc/guest-account/ Anyone can buy or solicit donations of hardware and build/test on those. Anyone can use the existing services (LAVA, GCC, OpenPOWER and cloud providers). https://wiki.debian.org/Hardware/Wanted -- 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/caktje6emm99jkljpuqy+bnqzbqmy4m4cy447afvhr9-8qjv...@mail.gmail.com
Re: Developer repositories for Debian
El Diumenge, 10 de maig de 2015, a les 10:47:27, Paul Wise va escriure: On Sun, May 10, 2015 at 12:06 AM, Leopold Palomo-Avellaneda wrote: El Dissabte, 9 de maig de 2015, a les 09:23:26, Mechtilde va escriure: Why can't you use people.debian.org for this? It's not an option for a non developer member. :-( If you are a member of Debian, you have access to people.debian.org, whether you are a developer or a non-uploading member. I guess you are talking about people who are not members of Debian? If so, IIRC the proposed PPA system is not for people who are not members of Debian (except via sponsorship). people.d.o AFAIK is _only_ for DD. Anyway, if I can see it correctly it's only web space. My ppa propose could be also useful for Debian members. I think that new packages, are controller by ftp-masters, so any help to create a new package could be welcome. mentors.d.o could help, but you must sent the binary You can upload to mentors without sending binary packages, in fact mentors ignores any binary packages (except it checks them with lintian). One interesting thing of mentors is that the packages are checked by lintian, so you need some binary ... So, I think that it could be very interesting for the project to have some kind of service, similar to ppa that: Why is a service needed? Everyone who has a computer should be able to install a Debian chroot or VM, build there, test the resulting packages etc and publish them on their website. if I'm not wrong launchpad now has 36,357 projects. Every project could have more than one ppa, and could have not ppa. I think that it could be interesting ... I agree that Everyone who has a computer should be able to install a Debian chroot or VM, build there but test the resulting packages etc many times is better that someone more test it, because some more eyes could found more problems. Also, different environments could help to find strange incompatibilities. publish them on their website. Many people don't have website and don't want to maintain a website. Because I work for a public university and I have the resources to have a server connected 24/365 but not all the people have this kind services. I cannot understand why you have this opposition. They idea is that the project could offer the option to build packages for Debian. Another thing is that you could say that, then you will have a lot of packages, maybe without quality, and you don't want the make a relation between that packages and the official ones. But, this is another thing. For whom like me, want to build packages for the project, it could be a very useful tool. The only thing a service would be needed for is non-x86 architectures AFAICT. Not only non-x86. I work _only_ with amd64 arch. In theory, it should not be necessary to have another pbuild environment for 32 bit: they are quite identical. However, I can say that we suffered in one bug of our packages because, in 32 bits, sometimes FTBFS because an strange combination of memory and parallel compilation. And, we were three persons involved in that package: two uploaders and one sponsor. Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? signature.asc Description: This is a digitally signed message part.
Re: Developer repositories for Debian
Hi, Am Sonntag, den 10.05.2015, 10:47 +0800 schrieb Paul Wise: On Sun, May 10, 2015 at 12:06 AM, Leopold Palomo-Avellaneda wrote: El Dissabte, 9 de maig de 2015, a les 09:23:26, Mechtilde va escriure: Why can't you use people.debian.org for this? It's not an option for a non developer member. :-( [...] The only thing a service would be needed for is non-x86 architectures AFAICT. Very good idea. That would make our work a lot of easier and, I think, better -- bye, pabs CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54526 Niederkail Threema: SYR8SJXB IRC: j_...@freenode.net j_...@oftc.net My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Re: Developer repositories for Debian
On Sun, May 10, 2015 at 12:06 AM, Leopold Palomo-Avellaneda wrote: El Dissabte, 9 de maig de 2015, a les 09:23:26, Mechtilde va escriure: Why can't you use people.debian.org for this? It's not an option for a non developer member. :-( If you are a member of Debian, you have access to people.debian.org, whether you are a developer or a non-uploading member. I guess you are talking about people who are not members of Debian? If so, IIRC the proposed PPA system is not for people who are not members of Debian (except via sponsorship). mentors.d.o could help, but you must sent the binary You can upload to mentors without sending binary packages, in fact mentors ignores any binary packages (except it checks them with lintian). So, I think that it could be very interesting for the project to have some kind of service, similar to ppa that: Why is a service needed? Everyone who has a computer should be able to install a Debian chroot or VM, build there, test the resulting packages etc and publish them on their website. The only thing a service would be needed for is non-x86 architectures AFAICT. -- 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/caktje6fpk4sqd087n1jupp+fmkzp3cynana1drzewkjlt1d...@mail.gmail.com
Re: Developer repositories for Debian
Hello Am 05.05.2015 um 23:45 schrieb Mike Hommey: On Sun, May 05, 2013 at 02:22:04PM +0200, Joerg Jaspert wrote: Hello world, Now with wheezy happy and out the door, we should finally tackle a long open issue. Developer repositories (AKA PPA) for Debian. Now with jessie happy and out the door, what is the status of Developer repositories for Debian? Why can't you use people.debian.org for this? Kind regards Mike -- Mechtilde Stehmann ## PGP encryption welcome ## Key-ID 0x141AAD7F signature.asc Description: OpenPGP digital signature
Re: Developer repositories for Debian
El Dissabte, 9 de maig de 2015, a les 09:23:26, Mechtilde va escriure: Hello Am 05.05.2015 um 23:45 schrieb Mike Hommey: On Sun, May 05, 2013 at 02:22:04PM +0200, Joerg Jaspert wrote: Hello world, Now with wheezy happy and out the door, we should finally tackle a long open issue. Developer repositories (AKA PPA) for Debian. Now with jessie happy and out the door, what is the status of Developer repositories for Debian? Why can't you use people.debian.org for this? It's not an option for a non developer member. :-( I think that this topic seems not be a interesting and to me it's a very frustrating issue. Let me explain my case: I'm a new maintainer and I'm working hard with another person to build a huge number of packages for robotics. But, this situation could be similar for other people. If I'm not wrong, if someone wants to contribute packaging for Debian, more or less must: a) take a upstream package that you want to work on b) work on the package, copyrights, lintian clean, etc. It's better to work in a good environment, like pbuilder, or similar. c) test the package. d) search for a sponsor, to upload the package for the revision of ftp-masters e) maintain it (bugs, transitions, etc) Before to arrive to point d), there are a lot of things to do. In my case I have had to create pbuilder environment (to work with), and a reprepro repository (to install easily in my boxes). It's not too much work, but it's time and for instance, I'm not able to test in exotic architectures or different ones than the typical x86. mentors.d.o could help, but you must sent the binary and _only_ checks the package with lintian. Because several reasons I try to avoid to work with any Ubuntu service. However, my partner convince me and prepare a ppa for our packages. And, it worked really well! IMHO it's a wonderful tool to work with. When you thing that your package it's more or less ok, you sent with dput the sources to the launchpad and it builds your package and if all is ok, it publishes it automatically (for i386 and amd64). If you work with several packages, it takes the dependencies from your ppa (or other you have configured?). It saves a lot of time. My first though was, ok, I can create a ppa for any Ubuntu version, maybe I could create for a Debian one, as Ubuntu derives from Debian it should be natural. But no [1], and IMHO there are not any interest to do that. Canonical help you, and promote you that build any Debian package for Ubuntu, but no the reversal order. I know that some people have tried to make a similar service [2], but there's no publish option of the package and lacks several things. So, I think that it could be very interesting for the project to have some kind of service, similar to ppa that: 1) let the people built his/her package in a Sid, stable-backport environment, or custom (stable+some addons) 2) Check the package built with lintian plus some licensecheck or whatever. 3) publish the package to be tested . This service could be a complement to mentors or Alioth. Also, maybe it could help to ftp-masters/sponsors if you try to publish your package and pass all the checks or show some important information about it. Of course it could have problems: - depending of the numbers of architectures supported, and the number of users, you could have a saturated service. - I don't know which legal problems the organization could have is someone upload to that service some software with some problematic license. - other problems that I'm almost sure that people in this list will find ;-) So, that's my opinion, thanks for reading. Leopold [1] https://bugs.launchpad.net/launchpad/+bug/188564 [2] http://debomatic-amd64.debian.net/ -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? signature.asc Description: This is a digitally signed message part.
Re: Developer repositories for Debian
On Sun, May 05, 2013 at 02:22:04PM +0200, Joerg Jaspert wrote: Hello world, Now with wheezy happy and out the door, we should finally tackle a long open issue. Developer repositories (AKA PPA) for Debian. Now with jessie happy and out the door, what is the status of Developer repositories for Debian? Mike -- 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/20150505214524.ga28...@glandium.org
Re: Web ID as passwordless authentication for debian web services [was: Re: Developer repositories for Debian]
Hi. Philip Hands p...@hands.com writes: Do you have any thoughts on how that compares with using BrowserID/Persona? I'd got the impression that BrowserID has been put together learning from mistakes of OpenID WebID, but perhaps I'm just swallowing their marketing. AFAIU, I guess that, at least from the user-friendliness POV, the main perceptible difference, is : - OpenID uses a URL as a person's identifier : may or not be easily copied/remembered/dictated - WebID uses a URL too, same problems (there are other benefits over OpenID, however, but limiting this post to this aspect of user friendliness only) - BrowserID uses a mail like identifier, which we seem to have gotten used to remember more easily, it seems. There are tons of other aspects to compare, of course, but from the marketing POV, these are quite importants ones ;) My 2 cents, Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip2i9ggb@inf-8657.int-evry.fr
Re: Developer repositories for Debian
Hi. Sorry to be a bit late in the discussion. Russ Allbery r...@debian.org writes: I'd never heard of WebID before this thread, but looking briefly at the spec, I share Daniel's concerns. I don't see how this eliminates reliance on the normal CAs. You still have to do certificate validation to be able to trust the link between URL and keypair, and the WebID protocol provides no way to do that certificate validation other than the normal CA process (and doesn't provide any alternative CA). I'm not sure I understand all aspects of the recent evolutions of the WebID auth protocols nor the big picture, but my understanding is that to auth to a server using a WebID (i.e. a URI pointing to a RDF document which declares a SSL cert public key), all that is required is that the connecting client owns the corresponding private key. This can be a locally generated cert, most likely in the user's browser cert, that has not been signed by any CA. It could also be a cert generated by a CA and imported in that browser's store. So there's in principle no need for CAs in WebID Auth. But of course, when you need to trust that cert for granting authorization after this authentication, there comes the need for signatures, etc. and maybe CAs could come into play. If you're going to trust the normal CAs anyway, all that WebID is really giving you is the ability to add additional metadata to the user's public certificate by publishing it at a linked URL; you're still trusting the public CAs implicitly to verify that user's certificate. I'd say that the benefit of the (FOAF) meta-data that can be loaded at the URI pointed to by the WebID is that there can be many things there, like mention of a GPG public key, elements of signature to assert that the WebID document is indeed owned by the owner both of the SSL cert, a certain GPG key, and maybe some endorsement by CAs and or peers (WoT signatures, etc.) So I'd say that CAs may or not participate in stating (through signature of the user's cert, or his her FOAF document ?) whether the SSL client cert is actually owned by whoever tries to auth. My understanding is that it could be pretty easy to check that the FOAF document of a WebID is actually signed by the GPG key of a Debian dev (maybe as it has been submitted to our servers in attachment of a signed mail) and then from that point on, we could trust the asociated SSL cert, whatever signatures it may have... but maybe that's a flawed trust chain ? Furthermore, you're not even using a direct CA signature, but rather are using the server certificate of the web server the user gives you in the URL to validate that their *client* certificate is owned by them. I haven't fully thought through the implications of that, but at first glance it strikes me as a repurposing of authentication data in a way that isn't theoretically sound. I'm not sure I understand the issue you're mentioning here. My understanding is that a FOAF document of a user's WebID may be accessible anywhere, and that URL isn't necessarily tied to where the SSL cert has been created. In principle, I can have bought a client cert from any cartel CA (actually, made it signed by them) and use it in association to any URL on a server supposedly under my control. WebID is trying to solve both the authentication problem and the distributed identity management problem. As was mentioned in later responses, there are actually several aspects of WebID, and IDentification and Authentication are actually being standardized in a more separated way, AFAIU. Do we actually need the identity management functionality? If not, then the FOAF data isn't needed, and an X.509 certificate from a Debian CA that issues certificates based on GnuPG-signed requests would be sufficient for us to bootstrap our own X.509 infrastructure without all the additional complexity of WebID. (With the caveat, as mentioned previously, that we'd have to do some thinking about expiration times and revocation.) I think there's some benefits of using FOAF to describe our project members, which was the point of my original mention of WebID on debian-project [0]. See also my experiment with webid.debian.net which provides FOAF documents for Debian participants [1], which I announced on debian-project@. But given that we're also thinking about auth mechanisms, and those FOAFs may be tied to SSL certs (in turn tied to our GPG WoT ?), then this seems quite compatible... and maybe more than other solutions that were mentioned, like OpenID or BrowserID. I hope this helps, and I've not responded to a too early message... sorry, but couldn't take the time to dig in the thread earlier. Will add a few more bits later in the thread too, most probably. Best regards, [0] http://lists.debian.org/debian-project/2013/02/msg00048.html [1] http://wiki.debian.org/WebIDDebianNet -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id:
Re: Developer repositories for Debian
ober...@debian.org writes: Russ Allbery r...@debian.org writes: I'd never heard of WebID before this thread, but looking briefly at the spec, I share Daniel's concerns. I don't see how this eliminates reliance on the normal CAs. You still have to do certificate validation to be able to trust the link between URL and keypair, and the WebID protocol provides no way to do that certificate validation other than the normal CA process (and doesn't provide any alternative CA). I'm not sure I understand all aspects of the recent evolutions of the WebID auth protocols nor the big picture, but my understanding is that to auth to a server using a WebID (i.e. a URI pointing to a RDF document which declares a SSL cert public key), all that is required is that the connecting client owns the corresponding private key. Here's the security problem in a nutshell (since I'm not sure anyone has said it outright in this thread): suppose that I am known to a particular server as https://www.eyrie.org/~eagle/personal/id#me. Suppose an attacker wishes to authenticate as me. The attacker would do the following: 1. Generate a new public/private key pair with that URI in the appropriate field so that it looks like a WebID certificate for that URI. 2. Set up a web server that serves the appropriate WebID metadata including their new certificate at that URI. 3. Visit the server they wish to attack to trigger the metadata request to my identity URI. 4. Hijack that metadata identity request so that it goes to their server instead of mine. This can be done in any number of ways (DNS cache poisoning, compromise of www.eyrie.org, compromise of my account on www.eyrie.org, TCP active MITM, etc.) depending on the situation. The server then retrieves the attacker's WebID document, verifies that the certificates match, and allows the attacker into the system as me. The only way to prevent this attack in WebID that I see is to either do leap-of-faith permanent caching (in other words, any server that I authenticate to caches all my cert information and never lets me change it subsequently), which is probably an unacceptable loss in functionality, or to secure the connection to my identity URI. If that endpoint is compromised, WebID loses in general (and probably can't be expected to defend against that). However, other major authentication systems are at least robust against DNS poisoning and TCP MITM. The obvious way to authenticate the connection to www.eyrie.org to retrieve my metadata is to validate the www.eyrie.org certificate against a CA, which is where the CA cartel is reintroduced into the picture. Please note that 4 is not as difficult as it looks, particularly if one of the goals is to allow more ad hoc servers that are possibly mobile, using untrusted wireless networks, or the like, rather than hosted in data centers with locked-down networks and physical security. Put more succinctly, as I understand the protocol, WebID is only as secure as the connection from the authenticating server to the metadata URI. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txm1d328@windlord.stanford.edu
Re: Developer repositories for Debian
Le 17/05/2013 17:43, Russ Allbery a écrit : [...] 4. Hijack that metadata identity request so that it goes to their server instead of mine. This can be done in any number of ways (DNS cache poisoning, compromise of www.eyrie.org, compromise of my account on www.eyrie.org, TCP active MITM, etc.) depending on the situation. [...] The obvious way to authenticate the connection to www.eyrie.org to retrieve my metadata is to validate the www.eyrie.org certificate against a CA, which is where the CA cartel is reintroduced into the picture. But if www.eyrie.org is compromised (as you seem to allow), then having a CA-certified certificate won't help, will it? I wouldn't rely on a trust chain involving an online private key in this context... -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51965590.2030...@debian.org
Re: Developer repositories for Debian
Stéphane Glondu glo...@debian.org writes: Le 17/05/2013 17:43, Russ Allbery a écrit : [...] 4. Hijack that metadata identity request so that it goes to their server instead of mine. This can be done in any number of ways (DNS cache poisoning, compromise of www.eyrie.org, compromise of my account on www.eyrie.org, TCP active MITM, etc.) depending on the situation. [...] The obvious way to authenticate the connection to www.eyrie.org to retrieve my metadata is to validate the www.eyrie.org certificate against a CA, which is where the CA cartel is reintroduced into the picture. But if www.eyrie.org is compromised (as you seem to allow), then having a CA-certified certificate won't help, will it? I think you read past the bit where I addressed that point. (I buried it in another paragraph, so that's not really surprising. Sorry!) If that endpoint is compromised, WebID loses in general (and probably can't be expected to defend against that). However, other major authentication systems are at least robust against DNS poisoning and TCP MITM. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ne1d1nw@windlord.stanford.edu
Re: Web ID as passwordless authentication for debian web services [was: Re: Developer repositories for Debian]
On 2013-05-16 at 14:12:33, Daniel Kahn Gillmor wrote: It looks to me like BrowserID/Persona will only work in web browsers with a functional javascript stack (and eventually, with a functional javascript crypto stack). The client authentication happens inside the TLS layer, over the HTTP protocol. That's right for BrowserID itself, but Luke Howard started building a protocol on top of BrowserID to make it usable outside of the browser: https://hacks.mozilla.org/2013/04/mozilla-persona-for-the-non-web/ PS thanks for keeping me cc'ed on replies Same here :) Francois -- Francois Marier identi.ca/fmarier http://fmarier.org twitter.com/fmarier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130518051621.ga30...@isafjordur.dyndns.org
Re: Web ID as passwordless authentication for debian web services [was: Re: Developer repositories for Debian]
On 2013-05-17 at 10:08:20, Olivier Berger wrote: AFAIU, I guess that, at least from the user-friendliness POV, the main perceptible difference, is : - OpenID uses a URL as a person's identifier : may or not be easily copied/remembered/dictated - WebID uses a URL too, same problems (there are other benefits over OpenID, however, but limiting this post to this aspect of user friendliness only) - BrowserID uses a mail like identifier, which we seem to have gotten used to remember more easily, it seems. There are tons of other aspects to compare, of course, but from the marketing POV, these are quite importants ones ;) I would argue that protecting user privacy is also relevant in the context of being friendly to users ;) From that point of view, OpenID leaks (to your IdP) the list of sites you log into whereas BrowserID is designed to prevent that. I don't know about WebID. Francois -- Francois Marier identi.ca/fmarier http://fmarier.org twitter.com/fmarier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130518052045.gb30...@isafjordur.dyndns.org
Re: Web ID as passwordless authentication for debian web services [was: Re: Developer repositories for Debian]
Le 16/05/2013 05:04, Philip Hands a écrit : Do you have any thoughts on how that compares with using BrowserID/Persona? I'd got the impression that BrowserID has been put together learning from mistakes of OpenID WebID, but perhaps I'm just swallowing their marketing. IIUC, there is no transfer of metadata (name, etc.) with BrowserID, unlike OpenID and WebID. An identity is an e-mail address, period. A benefit compared to OpenID and WebID is that the relying party doesn't need to query the identity provider each time, so this improves privacy. BrowserID also relies on the CA cartel. You need to setup an HTTPS (with a trusted certificate) server that responds to some hard-coded path [1] to implement an identity provider. I see this as a serious limitation, but I guess big identity providers don't care. There is an open issue [1] about looking up information in DNS instead of the current hard-coded path. Maybe this, combined with DNSSEC, could lift the HTTPS constraint. But this is work in progress. [1] https://developer.mozilla.org/en-US/docs/Mozilla/Persona/Implementing_a_Persona_IdP [2] https://github.com/mozilla/browserid/issues/1523 Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51949f6f.3010...@debian.org
Re: Web ID as passwordless authentication for debian web services [was: Re: Developer repositories for Debian]
Quoting Stéphane Glondu (2013-05-16 10:57:19) Le 16/05/2013 05:04, Philip Hands a écrit : Do you have any thoughts on how that compares with using BrowserID/Persona? I'd got the impression that BrowserID has been put together learning from mistakes of OpenID WebID, but perhaps I'm just swallowing their marketing. IIUC, there is no transfer of metadata (name, etc.) with BrowserID, unlike OpenID and WebID. An identity is an e-mail address, period. Sounds like your are describing (optional(?) extensions to) OpenID. With WebID only an ID is transfered. That transfered ID is a URI pointing to a resource optionally containing more info. A benefit compared to OpenID and WebID is that the relying party doesn't need to query the identity provider each time, so this improves privacy. Again, sounds like you are describing OpenID only. WebID allows (and encourages) caching. BrowserID also relies on the CA cartel. You need to setup an HTTPS (with a trusted certificate) server that responds to some hard-coded path [1] to implement an identity provider. I see this as a serious limitation, but I guess big identity providers don't care. There is an open issue [1] about looking up information in DNS instead of the current hard-coded path. Maybe this, combined with DNSSEC, could lift the HTTPS constraint. But this is work in progress. This seems similar as WebID: In principle ties to HTTPS - and therefore the CA cartel - is only optional (other URIs than http ones suffice). In reality alternatives to HTTP(S) is work in progress. If I understand correctly, BrowserID is by design tied to browsers - i.e. humans identifying themselves towards servers. WebID is not tied to browsers: it is equally useful for server-to-server communication. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130516102031.29499.62...@bastian.jones.dk
Re: Web ID as passwordless authentication for debian web services [was: Re: Developer repositories for Debian]
On 05/15/2013 11:04 PM, Philip Hands wrote: Do you have any thoughts on how that compares with using BrowserID/Persona? I'd got the impression that BrowserID has been put together learning from mistakes of OpenID WebID, but perhaps I'm just swallowing their marketing. It looks to me like BrowserID/Persona will only work in web browsers with a functional javascript stack (and eventually, with a functional javascript crypto stack). The client authentication happens inside the TLS layer, over the HTTP protocol. If i understand the parts of WebID that intend to perform authentication correctly, it uses standard TLS client-side certificates to do pubkey authentication of the client *at* (not inside) the TLS layer, and only requires the use of HTTP(S) in one small place: on the backend for servers who need to do key discovery via that mechanism. Since i'm the kind of person who uses TLS to wrap protocols other than HTTP (though i also use it around HTTP), i'd prefer to adopt an authentication regime that isn't limited to that one protocol inside TLS, but rather to work at the TLS layer directly. For example: it looks possible to use WebID for authentication in an IMAP client capable of STARTTLS. Even if we limit ourselves to the HTTPS subset of the 'net, i'm also the kind of person who browses the web with javascript disabled most of the time (and uses and implements automated HTTPS clients that have no HTML DOM support, let alone javascript support), i'd also prefer to adopt an authentication regime that doesn't necessarily rely on javascript or the HTML DOM. For these reasons (which i think are relevant to debian), what i think folks are referring to as WebID here (client-side certs verified by some robust mechanism other than the standard CA cartel) sounds better than BrowserID to me. It's possible that i've misunderstood or mischaracterized any of the protocols or tools mentioned here, though. if that's the case, i hope that someone will correct me. Regards, --dkg PS thanks for keeping me cc'ed on replies signature.asc Description: OpenPGP digital signature
Re: Web ID as passwordless authentication for debian web services [was: Re: Developer repositories for Debian]
Daniel Kahn Gillmor d...@fifthhorseman.net writes: On 05/14/2013 10:03 AM, Jonas Smedegaard wrote: I have also thought WebID would be a perfect match for things like this. [...] Daniel has raised concerns about WebID: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-March/001030.html Quite frustrating, because I trust Daniels reasonings on crypto matters far better than my own, yet feel strongly that WebID is the right way to go for loosely coupled trust chains like this. I think the way forward is for someone understanding WebID deeply to explain it to Daniel and others working on Monkeysphere, to get it integrated there. As I understand it, technically the paperkey tool can be used to to flesh out the core crypto material from a GPG (sub!)key and wrapping that into an SSL key should be the way to go. But that alone is not enough: We also need trust in WebID from those in Debian deeply understanding crypto. Cc'ing Daniel, hoping he has time to shed some renewed light on this. Web ID as a key verification mechanism has problems with centralized authority. Passwords have their own (distinct) set of serious problems, as far as i can tell. However, if we use Web ID as a key discovery mechanism and use other (non-centralized, non-third-party) mechanisms to validate the keys found therein, that seems like one decent way forward. Do you have any thoughts on how that compares with using BrowserID/Persona? I'd got the impression that BrowserID has been put together learning from mistakes of OpenID WebID, but perhaps I'm just swallowing their marketing. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgp6g19mI_vHD.pgp Description: PGP signature
Re: Developer repositories for Debian
Russ Allbery r...@debian.org writes: Raphael Hertzog hert...@debian.org writes: On Mon, 06 May 2013, Joerg Jaspert wrote: Nah, the webinterface just should end up like the DAM webinterface: You do whatever you need, then click a button - and voila, there is everything ready to copy/paste into a MUA. Send with sig, done. Why? This is just a band-aid and not what I would call a web interface. And except lazyness I don't see a good reason for that. Web interfaces can be secure (and with an audit trail in case of breach). After all we can manage our Debian passwords over a web interface... That level of security isn't great, though. GPG keys are much more secure than that password. What we would want for equivalent security in a web interface is personal X.509 certificates. WebID [0] could be useful in this respect. It includes the use of SSL certs for authentication, in addition to other benefits (see some discussion in the thread at [1]). I think it would be interesting to have that infrastructure in place, but someone would need to build it (probably with some mechanism to bootstrap GPG keys into X.509 certificates -- and be careful of expiration times and figure out a good way to deal with revocation). I'm not so sure how GPG integrates in the WebID landscape, but it seems to me that WebID, based on Linked Data principles has some similarity with Web of Trust concepts well known in the GPG system. Just my 2 cents, [0] http://webid.info/ [1] http://lists.debian.org/debian-project/2013/02/msg00048.html -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738tpwxtk@inf-8657.int-evry.fr
Re: Developer repositories for Debian
On Tue, May 14, 2013 at 02:27:51PM +0200, Olivier Berger wrote: Nah, the webinterface just should end up like the DAM webinterface: You do whatever you need, then click a button - and voila, there is everything ready to copy/paste into a MUA. Send with sig, done. Why? This is just a band-aid and not what I would call a web interface. And except lazyness I don't see a good reason for that. Web interfaces can be secure (and with an audit trail in case of breach). After all we can manage our Debian passwords over a web interface... That level of security isn't great, though. GPG keys are much more secure than that password. What we would want for equivalent security in a web interface is personal X.509 certificates. WebID [0] could be useful in this respect. It includes the use of SSL certs for authentication, in addition to other benefits (see some discussion in the thread at [1]). Or, we can just add this to dcut, like with DM permissions, and move on with all of our lives -- I mean, we're using this tool to push stuff, it seems sane to keep it all in one place, anyway. Once the format is nailed down, I'll add this to dput-ng. Right. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: Developer repositories for Debian
Quoting Olivier Berger (2013-05-14 14:27:51) Russ Allbery r...@debian.org writes: Raphael Hertzog hert...@debian.org writes: On Mon, 06 May 2013, Joerg Jaspert wrote: Nah, the webinterface just should end up like the DAM webinterface: You do whatever you need, then click a button - and voila, there is everything ready to copy/paste into a MUA. Send with sig, done. Why? This is just a band-aid and not what I would call a web interface. And except lazyness I don't see a good reason for that. Web interfaces can be secure (and with an audit trail in case of breach). After all we can manage our Debian passwords over a web interface... That level of security isn't great, though. GPG keys are much more secure than that password. What we would want for equivalent security in a web interface is personal X.509 certificates. WebID [0] could be useful in this respect. It includes the use of SSL certs for authentication, in addition to other benefits (see some discussion in the thread at [1]). I have also thought WebID would be a perfect match for things like this. I think it would be interesting to have that infrastructure in place, but someone would need to build it (probably with some mechanism to bootstrap GPG keys into X.509 certificates -- and be careful of expiration times and figure out a good way to deal with revocation). I'm not so sure how GPG integrates in the WebID landscape, but it seems to me that WebID, based on Linked Data principles has some similarity with Web of Trust concepts well known in the GPG system. Daniel has raised concerns about WebID: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-March/001030.html Quite frustrating, because I trust Daniels reasonings on crypto matters far better than my own, yet feel strongly that WebID is the right way to go for loosely coupled trust chains like this. I think the way forward is for someone understanding WebID deeply to explain it to Daniel and others working on Monkeysphere, to get it integrated there. As I understand it, technically the paperkey tool can be used to to flesh out the core crypto material from a GPG (sub!)key and wrapping that into an SSL key should be the way to go. But that alone is not enough: We also need trust in WebID from those in Debian deeply understanding crypto. Cc'ing Daniel, hoping he has time to shed some renewed light on this. - Jonas [interest]: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-March/000836.html [scepticism]: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-August/002426.html -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130514140321.23166.32...@bastian.jones.dk
Re: Developer repositories for Debian
Jonas Smedegaard d...@jones.dk writes: Quoting Olivier Berger (2013-05-14 14:27:51) I'm not so sure how GPG integrates in the WebID landscape, but it seems to me that WebID, based on Linked Data principles has some similarity with Web of Trust concepts well known in the GPG system. Daniel has raised concerns about WebID: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-March/001030.html Quite frustrating, because I trust Daniels reasonings on crypto matters far better than my own, yet feel strongly that WebID is the right way to go for loosely coupled trust chains like this. I'd never heard of WebID before this thread, but looking briefly at the spec, I share Daniel's concerns. I don't see how this eliminates reliance on the normal CAs. You still have to do certificate validation to be able to trust the link between URL and keypair, and the WebID protocol provides no way to do that certificate validation other than the normal CA process (and doesn't provide any alternative CA). If you're going to trust the normal CAs anyway, all that WebID is really giving you is the ability to add additional metadata to the user's public certificate by publishing it at a linked URL; you're still trusting the public CAs implicitly to verify that user's certificate. Furthermore, you're not even using a direct CA signature, but rather are using the server certificate of the web server the user gives you in the URL to validate that their *client* certificate is owned by them. I haven't fully thought through the implications of that, but at first glance it strikes me as a repurposing of authentication data in a way that isn't theoretically sound. WebID is trying to solve both the authentication problem and the distributed identity management problem. Do we actually need the identity management functionality? If not, then the FOAF data isn't needed, and an X.509 certificate from a Debian CA that issues certificates based on GnuPG-signed requests would be sufficient for us to bootstrap our own X.509 infrastructure without all the additional complexity of WebID. (With the caveat, as mentioned previously, that we'd have to do some thinking about expiration times and revocation.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3n14i5f@windlord.stanford.edu
Web ID as passwordless authentication for debian web services [was: Re: Developer repositories for Debian]
On 05/14/2013 10:03 AM, Jonas Smedegaard wrote: I have also thought WebID would be a perfect match for things like this. [...] Daniel has raised concerns about WebID: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-March/001030.html Quite frustrating, because I trust Daniels reasonings on crypto matters far better than my own, yet feel strongly that WebID is the right way to go for loosely coupled trust chains like this. I think the way forward is for someone understanding WebID deeply to explain it to Daniel and others working on Monkeysphere, to get it integrated there. As I understand it, technically the paperkey tool can be used to to flesh out the core crypto material from a GPG (sub!)key and wrapping that into an SSL key should be the way to go. But that alone is not enough: We also need trust in WebID from those in Debian deeply understanding crypto. Cc'ing Daniel, hoping he has time to shed some renewed light on this. Web ID as a key verification mechanism has problems with centralized authority. Passwords have their own (distinct) set of serious problems, as far as i can tell. However, if we use Web ID as a key discovery mechanism and use other (non-centralized, non-third-party) mechanisms to validate the keys found therein, that seems like one decent way forward. I'd be happy to see debian lead the way on using passwordless client authentication on the web; other (non-debian) groups might want to use similar infrastructure, and may even be willing to accept centralized, third-party points of control. They might still be better off than the current FAIL of trying to avoid authentication replay attacks by asking users politely to not reuse passwords across multiple authentication domains. I happen to think that debian is sufficiently capable that our internal infrastructure should not be able to be MITM'ed by, say, the next Diginotar (and it should not be DoS'ed by such a disaster either, the way .nl was). If adopting WebID puts us in that boat, that would be a sad thing. But i'm not saying anything that our DSA doesn't already know, and they're better sysadmins than that. And as a project, we already have a community-reinforced authentication infrastructure (the OpenPGP certification network that all contributors have to be connected to, as guided by the excellent debian-keyring maintainers) that we could tie that key verification to without exposing ourselves to greater risk from the diginotars of the world. if i can help in implementing a debian-keyring-derived verification of Web-ID-discovered keys for client-side TLS authentication, i'd be happy to try to pitch in in my copious (why is there no sarcasm emoticon yet?) free time. Regards, --dkg PS please cc me on followup. signature.asc Description: OpenPGP digital signature
Re: Developer repositories for Debian
On Fri, 10 May 2013, Paul Wise wrote: On Fri, May 10, 2013 at 4:33 AM, Russ Allbery wrote: That level of security isn't great, though. GPG keys are much more secure than that password. What we would want for equivalent security in a web interface is personal X.509 certificates. I think it would be interesting to have that infrastructure in place, but someone would need to build it (probably with some mechanism to bootstrap GPG keys into X.509 certificates -- and be careful of expiration times and figure out a good way to deal with revocation). That mechanism already exists (and supports SSH too): http://web.monkeysphere.info/ I don't think that you're speaking of the same thing. I see no information about X.509 client certificates in Monkeysphere. It offers ways to validate the server certificate (if it's not signed by known CA) but it doesn't seem to offer any solution to manage client certificate. That said, we already have http://sso.debian.org (http://wiki.debian.org/DebianSingleSignOn) that we should aim to leverage for authentication. And if it's not secure enough (and IIRC DSA doesn't want people to use this SSO for sensitive operations), then that's the single point where we should improve our infrastructure. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510061621.ga16...@x230-buxy.home.ouaza.com
Re: Developer repositories for Debian
On Fri, May 10, 2013 at 2:16 PM, Raphael Hertzog wrote: I don't think that you're speaking of the same thing. I see no information about X.509 client certificates in Monkeysphere. It offers ways to validate the server certificate (if it's not signed by known CA) but it doesn't seem to offer any solution to manage client certificate. That is something that is planned to be added: http://web.monkeysphere.info/FAQ/#index17h3 It is already supported by the OpenSSH parts. -- bye, pabs http://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: http://lists.debian.org/caktje6eymohemspeu+ot5uuafv4wsq0awn5kc39xdijjkdn...@mail.gmail.com
monkeysphere TLS client-side certs [was: Re: Developer repositories for Debian]
Raphaël wrote: I don't think that you're speaking of the same thing. I see no information about X.509 client certificates in Monkeysphere. It offers ways to validate the server certificate (if it's not signed by known CA) but it doesn't seem to offer any solution to manage client certificate. There actually is functional TLS client-side cert validation via the monkeysphere (checking identities against the OpenPGP WoT while keeping the bits on the wire as standard X.509), but it is in a development branch of mod_gnutls (not yet part of an official release). If either Bdale or I have signed your key (probably true for many DDs i've met at various debconfs) you can follow the steps at: https://demo.monkeysphere.info/ to see it in action. That demo is currently configured to rely on myself and bdale as certifying authorities, but the mechanism can be configured with arbitrary authorities (including using gpg's concept of marginal ownertrust), depending on the administrator's preferred configuration. I'm hoping to get a new release of mod_gnutls out relatively soon that should include this capability in an official release. Regards, --dkg PS Please Cc me on any replies because i am currently too short on time to drink directly from the firehose that is debian-devel :( pgpTZqkiViu46.pgp Description: PGP signature
Re: Developer repositories for Debian
Raphael Hertzog hert...@debian.org writes: On Mon, 06 May 2013, Joerg Jaspert wrote: Nah, the webinterface just should end up like the DAM webinterface: You do whatever you need, then click a button - and voila, there is everything ready to copy/paste into a MUA. Send with sig, done. Why? This is just a band-aid and not what I would call a web interface. And except lazyness I don't see a good reason for that. Web interfaces can be secure (and with an audit trail in case of breach). After all we can manage our Debian passwords over a web interface... That level of security isn't great, though. GPG keys are much more secure than that password. What we would want for equivalent security in a web interface is personal X.509 certificates. I think it would be interesting to have that infrastructure in place, but someone would need to build it (probably with some mechanism to bootstrap GPG keys into X.509 certificates -- and be careful of expiration times and figure out a good way to deal with revocation). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87haibnb9y@windlord.stanford.edu
Re: Developer repositories for Debian
On Fri, May 10, 2013 at 4:33 AM, Russ Allbery wrote: That level of security isn't great, though. GPG keys are much more secure than that password. What we would want for equivalent security in a web interface is personal X.509 certificates. I think it would be interesting to have that infrastructure in place, but someone would need to build it (probably with some mechanism to bootstrap GPG keys into X.509 certificates -- and be careful of expiration times and figure out a good way to deal with revocation). That mechanism already exists (and supports SSH too): http://web.monkeysphere.info/ The monkeysphere developers are Debian folks and have discussed monkeysphere with DSA at various DebConfs. -- bye, pabs http://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: http://lists.debian.org/CAKTje6FhKHGd7MVZ30zu6M_=okbsyenis1p8ptaak7gqcvl...@mail.gmail.com
Re: Developer repositories for Debian
Hi, On Mon, 06 May 2013, Joerg Jaspert wrote: Nah, the webinterface just should end up like the DAM webinterface: You do whatever you need, then click a button - and voila, there is everything ready to copy/paste into a MUA. Send with sig, done. Why? This is just a band-aid and not what I would call a web interface. And except lazyness I don't see a good reason for that. Web interfaces can be secure (and with an audit trail in case of breach). After all we can manage our Debian passwords over a web interface... Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130507062252.ga32...@x230-buxy.home.ouaza.com
Re: Developer repositories for Debian
Hi Jörg, we definitely needs something like this and your suggested set of rules seems sane. On Sun, 05 May 2013, Joerg Jaspert wrote: - any member of the uploading keyrings can create a PPAMAIN using a defined interface[1]. [1] Most probably it will either be a signed mail or a signed .commands style file. While I won't question the need to support signed mails or commands files, I would like to argue for the support of a web interface as well. The sheer number of operations that are possible on such repositories will make it difficult to remember the precise syntax of the various operations. A web interface is much more discoverable. Furthermore it's obvious that we will have web interfaces such as those used to track transitions and it would be nice if we could unify them at a single place (think: checking the tracker, then clicking a button to trigger/request a bin-nmu of foo, another button to import the correct version of bar, etc). I'm not asking you to create that web interface but at least to keep in mind the fact that someone might want to write it and as such to clearly separate what needs to be handled separately (mainly authentication I guess). Cheers, - Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130506070543.ge25...@x230-buxy.home.ouaza.com
Re: Developer repositories for Debian
Hi, On Montag, 6. Mai 2013, Raphael Hertzog wrote: While I won't question the need to support signed mails or commands files, I would like to argue for the support of a web interface as well. how about a web interface which creates such mails/commands, which then only need to be copied into the MUA, signed there and send?! That way there would be *no* attack vector from this webapp whatsoever. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Developer repositories for Debian
On Mon, May 06, 2013 at 09:05:43AM +0200, Raphael Hertzog wrote: While I won't question the need to support signed mails or commands files, I would like to argue for the support of a web interface as well. The sheer number of operations that are possible on such repositories will make it difficult to remember the precise syntax of the various operations. A web interface is much more discoverable. Furthermore Hi there, Raphaël, pleasure to speak with you, So, anyone creating such PPAs will understand how to use such tools as dput or dcut. Since dcut actually stands for debian command upload tool (and not some sort of cutting from the queue tool), we've added support for DM permissions in dcut from dput-ng. Stuff like $ dcut dm --uid Paul Tagliamonte --allow glibc Isn't so hard to use! (for those who are wondering, it looks up the name in the maintainer keyring and asks you to confirm the fingerprint ) I plan to add support for PPAs as well. Since DDs/DMs (unclear as to who can create these) know how to use such tools, I think it'll be much more secure if we require a GPG signature, like everywhere else :) Fondly, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: Developer repositories for Debian
On 13203 March 1977, Raphael Hertzog wrote: - any member of the uploading keyrings can create a PPAMAIN using a defined interface[1]. [1] Most probably it will either be a signed mail or a signed .commands style file. While I won't question the need to support signed mails or commands files, I would like to argue for the support of a web interface as well. Anyone is free to create one. The sheer number of operations that are possible on such repositories will make it difficult to remember the precise syntax of the various operations. A web interface is much more discoverable. Furthermore it's obvious that we will have web interfaces such as those used to track transitions and it would be nice if we could unify them at a single place (think: checking the tracker, then clicking a button to trigger/request a bin-nmu of foo, another button to import the correct version of bar, etc). I'm not asking you to create that web interface but at least to keep in mind the fact that someone might want to write it and as such to clearly separate what needs to be handled separately (mainly authentication I guess). Nah, the webinterface just should end up like the DAM webinterface: You do whatever you need, then click a button - and voila, there is everything ready to copy/paste into a MUA. Send with sig, done. Or it ends up giving you a commandline for $whatevertoolisTHEsuck on that day. -- bye, Joerg miro Alfie: warum heist du jetzt eigentlich Rhonda? maxx das ist heuer so mode... Rhonda 17:07 Rhonda Nein, ich erklärs nicht schon wieder nicht Rhonda 17:08 Rhonda 10mal nicht erklären muss genügen. maxx Rhonda ist die Frühjahrskollektion von Alfie :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87haif7vkv@gkar.ganneff.de
Developer repositories for Debian
Hello world, Now with wheezy happy and out the door, we should finally tackle a long open issue. Developer repositories (AKA PPA) for Debian. In this proposal we describe how a PPA setup properly integrated into Debian infrastructure *could* look like. Starting from general layout then going into technical details later on. Obviously this needs much more than just the FTPTeam to participate, we can think of at least DSA and the Buildd people, but there might be any number more. BACKGROUND: Debian would benefit from having a way for DDs to *easily* be able to prepare a set of packages, have them autobuilt and distributed to the users, WITHOUT all the constraints an upload to experimental or unstable includes. We intend to provide mechanisms to facilitate this in a way which will strike a balance between the ease of maintenance by developers and the ease of use by users while making sure that the integrity of the existing Debian suites is maintained and the potential additional legal liability this infrastructure might add is limited. DEFINITION OF TERMS (and they are lousy, go find better ones!): PPA: Personal Package Archive and used whenever something in this document applies to both, PPAMAIN and PPAEXT PPAMAIN: a PPA following all rules of the Debian archive and integrated into the archive. NEW packages need a full check, policy has to be followed, the usual deal. PPAEXT: PPA external to the archive, not integrated. Packages do not need to follow the full set of rules of the main archive and no NEW processing is done. Maintainer creating a PPAEXT have to agree to the Terms of service first, any content is the responsibility of the maintainer, not Debian! Current plan: We intent to implement PPAMAIN first, and when this is fully working we into to then setup a different archive to provide the PPAEXT service. Alternatively a different team can run it, but as much of the technic behind will be the same, we should ensure to not divide too much. Very lousy timeframe: I plan to put time into this after my vacation, so starting somewhere early in July. And then it depends how complicated it will be to implement this into the Debian infrastructure. I know what it takes for the archive, but I'm entirely out for the buildds and machines and whatever else otherwise. My hope is to get it implemented and usable archive side this year. Obviously help is always welcome, so if you want to help out, keep an eye on the discussion that I'm sure will arise from this mail - and join the debian-dak list in July. USAGE SCENARIOS: To make it a little bit easier to understand where this is coming from / leading us to, we thought of a few usage scenarios, together with the location they should use. Aggressive Backport: This is the dotdeb.org scenario. For whatever reason, people need whatever the latest version of php/mysql/apache/nginx/selectyourpoison is, compiled for (old)stable, in order to run on their otherwise stable servers. User needs this because they want to run the lastest version of CmsDuJour which requires brand new versions of php and mysql but those packages won't ever get moved back into Debian proper. This can go to PPAMAIN, as it only backports a defined set of packages already existing in the archive. Aggressive Experimental: This is the daily build of chromium scenario. It might be helpful to build a certain set of packages very often in a very recent version. Which shouldn't hit unstable yet or shouldn't block transitions. It probably works best with a limited set of architectures to not needlessly overload buildds of smaller/slower architectures. This would be another PPAMAIN, as it is merely a variation of the backport variant. Enthusiast Preview: This is the Iceweasel alpha scenario which might eliminate many uses of the current experimental suite or extra archives like mozilla.debian.net. Developers can have PPAs for alpha/beta releases, which don't get in the way of uploads to unstable that are targeting potential fixes to bugs in unstable/testing. This is for PPAMAIN. Same set of packages as in the archive, just ones with more possible problems. Preparing Transitions: Some base package(s) should be changed in a maybe incompatible way. All of its reverse (Build-)Depends will be rebuild, updated, and fixed in the PPA before they get transferred to unstable. PPAMAIN. Not Policy Compliant: A Vendor is distributing software which is going to be difficult to modify to fit Debian policy. It's therefore not fit for distribution along with the traditional Debian components, but the PPA creator got the right to distribute this piece further. There might not even be source, and it also insists on loading its config from /usr/local/sucky. PPAEXT, obviously.
Re: Developer repositories for Debian
Hi, let me comment Am Sonntag, den 05.05.2013, 14:22 +0200 schrieb Joerg Jaspert: Preparing Transitions: Some base package(s) should be changed in a maybe incompatible way. All of its reverse (Build-)Depends will be rebuild, updated, and fixed in the PPA before they get transferred to unstable. [..] - a PPAMAIN can have its full package set transferred into its base suite with one command, provided the base suite is configured to receive such transfers. (Currently we imagine only unstable will be configured for it, but other suites might gain this feature too). Only packages with versions NEWER than those existing in the base suite will be transferred. All version checks of the base suite must be fulfilled for the transfer to work. with a big: „Yes, thanks in advance“ from the Haskell team. This will allow us to keep the uninstallable count in unstable very low at all times, even while we rebuild stuff for a new compiler. Feature suggestion: Optionally only allow the package set transferred to unstable if all transferred packages are installable in the final set, or similar checks as applied in the unstable → testing transition. And a question: - a PPAMAIN must have packages with unique versions which have to be greater than in the base suite. Package versions are global for the archive, so the ppaname has to be included in the version uploaded to the PPA. What if it is decided by the maintainers of a certain package to do the uploads always to a PPA first and from there, via the above command, to unstable. Will it then be ok to use „normal“ version numbers? Greetings and thanks for the happy news, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Developer repositories for Debian
On 13202 March 1977, Joachim Breitner wrote: - a PPAMAIN can have its full package set transferred into its base suite with one command, provided the base suite is configured to receive such transfers. (Currently we imagine only unstable will be configured for it, but other suites might gain this feature too). Only packages with versions NEWER than those existing in the base suite will be transferred. All version checks of the base suite must be fulfilled for the transfer to work. with a big: „Yes, thanks in advance“ from the Haskell team. This will allow us to keep the uninstallable count in unstable very low at all times, even while we rebuild stuff for a new compiler. Yep, one of the reasons for it (though not with haskell especially in mind, there are more packages that profit from it). Feature suggestion: Optionally only allow the package set transferred to unstable if all transferred packages are installable in the final set, or similar checks as applied in the unstable → testing transition. That would mean having a kind-of-britney run, and only if that succeeds move it over. Should be doable, i think. - a PPAMAIN must have packages with unique versions which have to be greater than in the base suite. Package versions are global for the archive, so the ppaname has to be included in the version uploaded to the PPA. What if it is decided by the maintainers of a certain package to do the uploads always to a PPA first and from there, via the above command, to unstable. Will it then be ok to use „normal“ version numbers? Good question. The thought behind this is that a ppa haskell1 can contain package debhelper as well as a ppa ruby42 can contain it. Both with different changes to it. Which should work, and the easiest way to ensure that is that each new upload to a ppa includes its ppaname. -- bye, Joerg Cabal: lamont Those people, who, when they do something currently outside of the official rules for behavior [your choice here] 1) are exempted from censure, or 2) (more accurately) by their actions define a new set of rules for acceptable behavior in such context. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip2x4hk0@gkar.ganneff.de
Re: Developer repositories for Debian
On Sun, May 05, 2013 at 04:48:01PM +0200, Joerg Jaspert wrote: Feature suggestion: Optionally only allow the package set transferred to unstable if all transferred packages are installable in the final set, or similar checks as applied in the unstable → testing transition. That would mean having a kind-of-britney run, and only if that succeeds move it over. Should be doable, i think. That's a possibility, yes. If OTOH you only want to check for installability, you might simply run dose-distcheck on the involved packages (similarly to what the buildds do, except they do that for build dependencies, while you likely want to do that for binary package dependencies). Doing so might be simpler than having to support other britney runs/installations. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
