Re: New project goal: Get rid of Berkeley DB (post jessie)
Hi Dne Thu, 19 Jun 2014 12:26:48 +0200 Adrien CLERC napsal(a): > Le 19/06/2014 11:38, Ondřej Surý a écrit : > > List of affected maintainers follows: > > > > Loic Minier > >evolution-data-server (U) > >rpm (U) > > > I am just a simple user of rpm. Yes, I use rpm for inspecting, > debugging, and so on. I don't use it for managing packages on my Debian > box, but I guess that removing BerkeleyDB from rpm is not an option. If > I'm wrong, I'll be glad to hear it :) AFAIK it can use SQLite backend as well, I'll look at it before next upload... -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Bug#752387: ITP: r-cran-gsl -- GNU R wrapper for the GNU Scientific Library
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-gsl Version : 1.9-10 Upstream Author : Robin K. S. Hankin * URL : http://cran.r-project.org/web/packages/gsl/ * License : GPL Programming Lang: R Description : GNU R wrapper for the GNU Scientific Library An R wrapper for the special functions and quasi random number generators of the GNU Scientific Library (http://www.gnu.org/software/gsl/). Remark: Since this GNU R package is used in the test suite of package r-cran-spatstat and can enhance the spead of some specific functions in this package drastically it will be packaged for Debian as well. The packaging is done by the Debian Science team at svn://anonscm.debian.org/debian-science/packages/R/trunk/packages/r-cran-gsl/trunk/ -- 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/20140623094006.12055.76097.report...@mail.an3as.eu
Re: llvm-defaults vs update alternatives
On 22/06/2014 11:47, Christian Hofstaedtler wrote: > update-alternatives gives the user a choice, My remark is not directly related to this problem (perhaps, in fact) but update-alternatives does *not* give the user a choice. It give the *admin* a choice. You must be root to run update-alternatives and the choice affects all users of a system. If you are in a multiuser environment (or want to support such one), update-alternatives is not a solution. I would be very pleased if update-alternatives can work for users, at least for most packages. But it is another discussion. A+ Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- 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/53a81048.7020...@free.fr
Bug#752396: ITP: r-cran-randomfields -- GNU R simulation and analysis of random fields
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-randomfields Version : 3.0.10 Upstream Author : Martin Schlather * URL : http://cran.r-project.org/web/packages/RandomFields/ * License : GPL Programming Lang: R Description : GNU R simulation and analysis of random fields This GNU R package can be used for simulation of Gaussian and extreme value random fields; conditional simulation; kriging; maximum likelihood estimation. Remark: This package is used in unit tests of r-cran-spatstat and thus it will be provided as Debian package as well to enable running the full test suite. The package is maintained by the Debian Science team at svn://anonscm.debian.org/debian-science/packages/R/trunk/packages/r-cran-randomfields/trunk/ -- 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/20140623115530.15131.64874.report...@mail.an3as.eu
Bug#752398: ITP: python-spyne -- Python RPC library for HttpRpc, SOAP, Json and more
Package: wnpp Severity: wishlist Owner: Russell Stuart * Package name: python-spyne Version : 2.10.10 Upstream Author : Burak Arslan * URL : http://spyne.io/ * License : LGPL Programming Lang: Python Description : Python RPC library for HttpRpc, SOAP, Json and more Spyne is a Python library for implementing RPC servers over HTTP and ZeroMQ using a multitude of serialisation formats, such as HttpRpc, SOAP, Json, XML. The signatures of the published functions and the data types passed as parameters and returned as results are obtained by introspecting the python code. Originally called soaplib, it was later renamed to rpclib, and then to spyne. -- 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/20140623121223.6063.43461.report...@russell-laptop.pc.brisbane.lube
Bug#752399: ITP: python-fdb -- Python DB-API driver for Firebird
Package: wnpp Severity: wishlist Owner: Russell Stuart * Package name: python-fdb Version : 1.4 Upstream Author : Pavel Cisar * URL : https://pypi.python.org/pypi/fdb/ * License : BSD Programming Lang: C, Python Description : Python DB-API driver for Firebird FDB is a Python library package that implements Python Database API 2.0-compliant support for the open source relational database Firebird®. In addition to the minimal feature set of the standard Python DB API, FDB also exposes nearly the entire native client API of the database engine. -- 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/20140623122052.6505.31970.report...@russell-laptop.pc.brisbane.lube
Re: software outside Debian (Re: holes in secure apt)
* Christoph Anton Mitterer , 2014-06-22, 04:34: There are a few mechanisms to mitigate downgrade attacks within the archive: * Valid-Until fields in the Release files; I still think the time spans are far too long here... For the record, the validity periods currently are: unstable, experimental: 7 days testing: 7 days wheezy: no limit wheezy(-proposed)-updates: 7 days wheezy/updates at security.d.o: 10 days wheezy-backports: 7 days squeeze: no limit squeeze(-proposed)-updates: 7 days squeeze/updates at security.d.o: 10 days squeeze-lts: 7 days I agree than they could be shorter (particularly the security.d.o ones raised my eyebrows), but I'm not going to lose sleep over it. can someone please tell me against what I could report a bug (i.e. politely ask for enhancement by making the time span much smaller)? My guesses would be: "reportbug ftp.debian.org" for unstable and experimental; "reportbug release.debian.org" for testing, (old)stable and their (proposed-)updates; team@security.d.o for the security.d.o archive; debian-lts@lists.d.o for squeeze-lts. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140623124258.ga7...@jwilk.net
Re: software outside Debian (Re: holes in secure apt)
On 2014-06-23 13:42, Jakub Wilk wrote: * Christoph Anton Mitterer , 2014-06-22, 04:34: There are a few mechanisms to mitigate downgrade attacks within the archive: * Valid-Until fields in the Release files; I still think the time spans are far too long here... For the record, the validity periods currently are: [...] can someone please tell me against what I could report a bug (i.e. politely ask for enhancement by making the time span much smaller)? My guesses would be: "reportbug ftp.debian.org" for unstable and experimental; "reportbug release.debian.org" for testing, (old)stable and their (proposed-)updates; team@security.d.o for the security.d.o archive; debian-lts@lists.d.o for squeeze-lts. Those are all dak configuration, so controlled by ftpmaster. Regards, Adam -- 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/b0ed4a308fd8c8f47cb23708bf94e...@mail.adsl.funky-badger.org
Re: HTTPS everywhere!
On Mon, 2014-06-23 at 08:58 +1000, Russell Stuart wrote: > > Well first, AFAIK, there are no mirrors for the BTS... and then > > securing something like BTS with OpenPGP is quite difficult. > There is a straight forward solution to handling BTS messages. You just > DKIM sign them with an appropriate key when they are received. Maybe my understanding of DKIM is too little... but I thought it would be only some technique to verify the authenticity of sender addresses? And as I've said... just signing somehow all the single mails that arrive at the BTS, which could be verified by clients when they read it is not enough. That would allow an attacker to easily filter out single messages... somehow you need to secure the series of all messages,... and also things like negative replies (e.e. "there is no bug for package xyz). And since many people interact with the BTS via web (well at least for reading) you're anyway obliged to support some https solution. > > Given that these services are used more and more for development, I > > think it's more and more important to secure them as far as possible. > 90% of what you want could be achieved with a working version of > Certificate Patrol. Well CP is at first unmaintained and it has many issues... and lacks many features (like telling it exactly which cert and or 1-n CAs to expect for a domain)... Then you have the problem that people don't just access https content via browsers, where one can easily integrate something like CP... they may make use of https in svn, git, etc. So you'd have to write something like CP for all these tools. And even if that would be done... you still have the main problem - and regardless of what you say this won't go away since it's an inherent problem of any strictly hierarchical PKI - that you cannot guarantee full security when you need trust some untrustworthy CA (i.e. any CA that is not under our - Debian's - control). Even if you have some pinning technique like CP in place,... than a non-Debian rogue CA can simply attack you on your first visit of https://whatever.debian.org/ and your CP is useless. > Ship it as a standard part of iceweasel, pre > configured with a few certs and enabled by default. Well again,... it's not only iceweasel that would needed to be secured but any other browser, git, svn, etc. pp. And even if you'd do that (really hardcoding the actual host certs)... than you have a completely unmaintainable system... you need to patch all programs for any new Debian host cert, for any one that expires or is revoked. This is probably 100 times the efforts of running a own CA. > That nice thing about getting Certificate Patrol working is it helps > everyone - not just Debian. Again... using CP alone won't make things secure - unless you really hard code all the single Debian host certs in all programs that use TLS/SSL (or at least with Debian services). And actually... just hard coding all our host certs wouldn't be enough... code would need to be added, that no other (i.e. non-hard-coded) cert may be used for any debian.org/net service. IMHO far too much effort. It's much easier to run our own Debian CA plus: - for most non-browser programs that allow to specify which CAs are trusted, only add that Debian CA - for browsers: hard code that Debian CA as the only one for debian.org| net Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: software outside Debian (Re: holes in secure apt)
On Mon, 2014-06-23 at 14:42 +0200, Jakub Wilk wrote: > For the record, the validity periods currently are: > > unstable, experimental: 7 days > testing: 7 days > > wheezy: no limit > wheezy(-proposed)-updates: 7 days > wheezy/updates at security.d.o: 10 days > wheezy-backports: 7 days > > squeeze: no limit > squeeze(-proposed)-updates: 7 days > squeeze/updates at security.d.o: 10 days > squeeze-lts: 7 days > > I agree than they could be shorter (particularly the security.d.o ones > raised my eyebrows), but I'm not going to lose sleep over it. Well I just think that most of the time, our Security Team does some very great job (if not hiding away issues o.O) and fixes are available in Debian very shortly after a fix is available. These guys put a lot effort into that, but their quick response is useless if those periods are so long. It gives an attacker that can MitM (and we must expect that not only the NSA can do this) 7-10 days (!!!) to conceal updates from a system and exploit the security holes they fix. Especially since many server systems update automatically, this is quite problematic IMHO. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: software outside Debian (Re: holes in secure apt)
For the interested: On Mon, 2014-06-23 at 14:42 +0200, Jakub Wilk wrote: > "reportbug ftp.debian.org" for unstable and experimental; #752450 smime.p7s Description: S/MIME cryptographic signature
Re: software outside Debian (Re: holes in secure apt)
* Adam D. Barratt , 2014-06-23, 14:24: * Christoph Anton Mitterer , 2014-06-22, 04:34: There are a few mechanisms to mitigate downgrade attacks within the archive: * Valid-Until fields in the Release files; I still think the time spans are far too long here... For the record, the validity periods currently are: [...] can someone please tell me against what I could report a bug (i.e. politely ask for enhancement by making the time span much smaller)? My guesses would be: "reportbug ftp.debian.org" for unstable and experimental; "reportbug release.debian.org" for testing, (old)stable and their (proposed-)updates; team@security.d.o for the security.d.o archive; debian-lts@lists.d.o for squeeze-lts. Those are all dak configuration, so controlled by ftpmaster. I don't doubt it. :-) What I doubt is that ftp-masters would be willing to alter the configuration without blessing of the respective teams. But I could be wrong, of course. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140623170043.gb6...@jwilk.net
Re: HTTPS everywhere!
On Mon, 2014-06-23 at 17:26 +0200, Christoph Anton Mitterer wrote: > Maybe my understanding of DKIM is too little... but I thought it would > be only some technique to verify the authenticity of sender addresses? DKIM, OpenPGP, X.509 - they are all the same thing with different names. They all compute a hash of a lump of data, and encrypt it using a asymmetric cypher. Given that, it just boils down to what data they encrypt and what crypto they use. For DKIM the signer gets to select what he signs - it could be the entire email, and the crypto is rsa-sha256. Key size isn't constrained, but is generally 2048 bits. The only reason I mentioned DKIM is the software is already written. It would be a few hundred lines of code, at most, to sign every incoming email. > And as I've said... just signing somehow all the single mails that > arrive at the BTS, which could be verified by clients when they read it > is not enough. > That would allow an attacker to easily filter out single messages... > somehow you need to secure the series of all messages,... and also > things like negative replies (e.e. "there is no bug for package xyz). > And since many people interact with the BTS via web (well at least for > reading) you're anyway obliged to support some https solution. The usual solution so that is what Debian uses for it's package archive. It's to sign the index of messages apt-listbugs downloads in order to find the emails to display. > Even if you have some pinning technique like CP in place,... than a > non-Debian rogue CA can simply attack you on your first visit of > https://whatever.debian.org/ and your CP is useless. You've lost me. Whether Debian is a CA or not it irrelevant for the initial download of software over the net. It will be done, by definition, using non-Debian software, which be using the X.509 PKI in the normal way. The normal way here implies they will trust every CA bundled into downloaded software. Including a Debian CA in that bundle doesn't help Debian's security in the slightest. Pinning is just another word for "I don't need to use the X.509 PKI, because I obtained the Debian certificate via a side channel". By definition that means whether Debian is a CA or not is irrelevant - because being a CA means "I am one of the privileged few whose certificates are distributed by the X.509 PKI". So yes, I agree pinning is useless when you first download the software. But nothing you have suggested so far is any better in that case. As far as I know, nothing can be any better. > Again... using CP alone won't make things secure - unless you really > hard code all the single Debian host certs in all programs that use > TLS/SSL (or at least with Debian services). For me "all programs" boils down to 1 - Firefox. Some others might use Chromium, which given Chrome supports Google's pinning its own certs probably could be hacked easily enough to support Debian doing the same thing. > It's much easier to run our own Debian CA plus: > - for most non-browser programs that allow to specify which CAs are > trusted, only add that Debian CA > - for browsers: hard code that Debian CA as the only one for debian.org| > net This looks like pinning under another name to me. And quoting you above, in this very same email, you say pinning is too hard because you have to "hard code all the single Debian host certs in all programs that use TLS/SSL (or at least with Debian services)". And yet now you say we have to do this anyway! Your insistence that Debian become a CA is now truly mystifying. There is only one reason to become CA, and that is so you can have your certificates distributed by the X.509 PKI. Yet you profoundly distrust the X.509 PKI, so much so (and imo with good reason) that you insist we don't use X.509 PKI at all when interacting with Debian, preferring to use a pinned Debian cert instead. So bother becoming a CA in the first place? signature.asc Description: This is a digitally signed message part
Re: HTTPS everywhere!
Hi, Russell Stuart: > This looks like pinning under another name to me. And quoting you > above, in this very same email, you say pinning is too hard because you > have to "hard code all the single Debian host certs in all programs that > use TLS/SSL (or at least with Debian services)". And yet now you say we > have to do this anyway! > The difference is that while pinning a bunch of certificates is indeed a lot of on-going work, pinning the CA cert used to sign these is not (set up the CA and install it into our software once, sign server certificates with that forevermore). -- -- Matthias Urlichs -- 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/20140624062942.ga27...@smurf.noris.de
Re: HTTPS everywhere!
On Tue, 2014-06-24 at 08:29 +0200, Matthias Urlichs wrote: > The difference is that while pinning a bunch of certificates is indeed a > lot of on-going work, pinning the CA cert used to sign these is not (set up > the CA and install it into our software once, sign server certificates with > that forevermore). If that is a huge problem you just pin the CA's cert. The assertion you are making is: all .debian.net/.debian.org's must be signed by this root. To compromise Debian the attacker must compromise a CA Debian chooses, not a CA of their choice. It's not a new idea - Certificate Patrol already does it. signature.asc Description: This is a digitally signed message part
