Re: jessie release goals

Le Fri, May 17, 2013 at 08:29:42PM -0600, Bob Proulx a écrit : > Andrei POPESCU wrote: > > Andreas Beckmann wrote: > > > now might be the right time to start a discussion about release goals > > > for jessie. > > > > How about setting default umask for users (uid >= 1000) to 002? > > +1. It wou

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

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 p

Re: Debian development and release: always releasable (essay)

On Thu, May 16, 2013 at 5:52 AM, Neil McGovern wrote: > On Thu, May 16, 2013 at 12:29:11AM +0200, Kurt Roeckx wrote: >> Some upstreams have a testing branch of there software and a >> release branch. It's sometimes useful to have people test the >> version in from the testing branch, and having it

Re: jessie release goals

Andrei POPESCU wrote: > Andreas Beckmann wrote: > > now might be the right time to start a discussion about release goals > > for jessie. > > How about setting default umask for users (uid >= 1000) to 002? +1. It would be a useful default. Bob signature.asc Description: Digital signature

Re: Depends: libfoo:foreign ???

On Fri, May 17, 2013 at 07:12:26PM -0400, The Wanderer wrote: > I can already say that it won't be binary identical to the 64+32 build, > because even the 64-bit standalone build isn't binary identical to the > 64-bit side of a combined build (even though they're configured the > exact same way). I

Re: Depends: libfoo:foreign ???

On 05/14/2013 09:40 AM, Goswin von Brederlow wrote: Could you build a 32bit only, a 64bit only and a 32+64bit wine, run make install for each case and generate a file list for each? Including "file" output so it shows what is 32bit and what 64bit in the mixed case. I have these file lists now,

Re: WebID as passwordless authentication for debian web services

Simon McVittie writes: > By way of context, OpenID originated on Livejournal as a way to have > federation between blogging platforms (e.g. other sites running the > Livejournal codebase). At the time, https was considered sufficiently > expensive that LJ didn't even use it to secure login, let a

Re: WebID as passwordless authentication for debian web services

Olivier Berger writes: > Russ Allbery writes: >> ober...@debian.org writes: >>> 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 >>>

Re: WebID as passwordless authentication for debian web services

On 17/05/13 17:36, Olivier Berger wrote: >> The only way to prevent this attack in WebID that I see is to either do >> leap-of-faith permanent caching [...] or >> to secure the connection to my identity URI. > > I wonder how OpenID, for instance, is supposed to resist to such > attacks, in compari

Re: /bin/sh

On Thu, May 16, 2013 at 01:10:06PM +0200, Goswin von Brederlow wrote: > On Tue, May 14, 2013 at 12:21:33PM -0500, Steve Langasek wrote: > > On Tue, May 14, 2013 at 10:03:34AM -0700, Russ Allbery wrote: > > > I think that, to convince people that flexibility won't cause stability > > > and complexi

Re: WebID as passwordless authentication for debian web services

Hi. Russ Allbery writes: > ober...@debian.org writes: >> 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

Re: Developer repositories for Debian

Stéphane Glondu 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 accoun

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 ac

Re: Developer repositories for Debian

ober...@debian.org writes: > Russ Allbery 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

Re: Web ID as passwordless authentication for debian web services

Stéphane Glondu writes: > Le 16/05/2013 18:37, Russ Allbery a écrit : >> Right, it depends on what your risk model is. If you're defending >> against incompetence and/or commercial greed overriding security >> practices, DNSSEC looks a lot more appealing than the CA cartel, since >> there isn't

Re: Do opaque struct changes break C library ABIs

Le 17/05/2013 15:45, Chow Loong Jin a écrit : But how do you load a plugin without using dlopen()? > [...] > Okay, so real shared libraries can't be dlopen()'d on some systems, and > plugins > still have to be dlopen()'d. That doesn't answer my question, really. It kind of does, actually :-)

Bug#708654: ITP: unittest-xml-reporting -- Python unittest-based test runner with Ant/JUnit like XML reporting

Package: wnpp Severity: wishlist Owner: Jonathan Wiltshire * Package name: unittest-xml-reporting Version : 1.4.3 Upstream Author : Daniel Fernandes Martins * URL : https://pypi.python.org/pypi/unittest-xml-reporting * License : GPL-3+ Programming Lang: Pytho

Re: Do opaque struct changes break C library ABIs

On 17/05/2013 19:50, Simon McVittie wrote: > On 17/05/13 10:43, Chow Loong Jin wrote: >> On 17/05/2013 13:17, Guillem Jover wrote: >>> I agree dlopen()ing shared libraries in general should not be >>> supported (I'd even go further and say this should be outright >>> banned, given the pain it caus

Re: Temporary solution for changelog problem in binNMUs

Le vendredi 17 mai 2013 15:36:02, Julien Cristau a écrit : > On Fri, May 17, 2013 at 14:14:20 +0200, Thomas Preud'homme wrote: > > Also, it wouldn't help for the case of a binNMU on a subset of all arches > > since only some of them would have the entry. The solution proposed by > > ansgar cover th

Re: Temporary solution for changelog problem in binNMUs

On Fri, May 17, 2013 at 14:14:20 +0200, Thomas Preud'homme wrote: > Also, it wouldn't help for the case of a binNMU on a subset of all arches > since only some of them would have the entry. The solution proposed by ansgar > cover this case. No it doesn't. dpkg will still refuse to install a m-

Re: /bin/sh (was Re: jessie release goals)

On 2013-05-07 14:23:47 +, Thorsten Glaser wrote: > Shells suitable for /bin/sh are currently bash, dash, mksh. I forgot about that (partly because of workarounds), but due to the SIGINT problem, I think that *currently*, among these 3 shells, bash is the most suitable one, and mksh is a bit be

Re: Do opaque struct changes break C library ABIs

Le 17/05/2013 14:18, Sune Vuorela a écrit : > On 2013-05-17, Simon McVittie wrote: >> dlopen()'d. However, GNU/anything and Windows (and also Mac OS, I >> think) are among the platforms where either works, so in practice most > > You can't link plugins on windows, I'm told. Indeed. Some informat

Re: Do opaque struct changes break C library ABIs

Le 17/05/2013 13:50, Simon McVittie a écrit : > According to libtool documentation, on some platforms this distinction > is really significant, and "real shared libraries" can't be > dlopen()'d. However, GNU/anything and Windows (and also Mac OS, I > think) are among the platforms where either work

Re: Do opaque struct changes break C library ABIs

On 2013-05-17, Simon McVittie wrote: > dlopen()'d. However, GNU/anything and Windows (and also Mac OS, I > think) are among the platforms where either works, so in practice most You can't link plugins on windows, I'm told. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.or

Re: Temporary solution for changelog problem in binNMUs

Le vendredi 17 mai 2013 13:40:13, Dominique Dumont a écrit : > > This may be a dumb question, but looking at this example of different > binNMU changelogs [1], I wonder what is the point of having a log specific > to each build system ... > > In other word, can't we have a binNMU log generated by

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)

Hi Marc, On Freitag, 17. Mai 2013, Marc Haber wrote: > We're going to have a TC decision or a GR about this anyway. why do you think so? cheers, Holger signature.asc Description: This is a digitally signed message part.

Re: Do opaque struct changes break C library ABIs

On 17/05/13 10:43, Chow Loong Jin wrote: > On 17/05/2013 13:17, Guillem Jover wrote: >> I agree dlopen()ing shared libraries in general should not be >> supported (I'd even go further and say this should be outright >> banned, given the pain it causes, and optional library support >> should always

Re: Temporary solution for changelog problem in binNMUs

On Monday 13 May 2013 11:14:07 Ansgar Burchardt wrote: > There have been previous discussions how to fix this[2]. The dpkg > maintainers would like to treat changelogs and copyright files as > metadata and move them out of /usr/share/doc[3]. > > [2]

Re: Web ID as passwordless authentication for debian web services

Hi again. Just in case it helps a bit more, let me forward you this message from Andrei Sambra, a Debian user and WebID working group member (who's also the developer of MyProfile, a "killer demo" service of WebID at [1] - project/code at [0]). Andrei read the thread an wanted to provide some fee

Re: Web ID as passwordless authentication for debian web services

Quoting Russ Allbery (2013-05-16 22:24:34) > Jonas Smedegaard writes: > > Quoting Russ Allbery (2013-05-16 19:57:59) > > >> Sure, but if you have control over the server certificate and are > >> tying the server certificate to the user certificate via some > >> mechanism like Monkeysphere, why

Re: Do opaque struct changes break C library ABIs

On 17/05/2013 13:17, Guillem Jover wrote: > Yeah that should be the case, the dynamic linker should not be > loading the same SONAME multiple times, so there should be no race > here, and I agree dlopen()ing shared libraries in general should not > be supported (I'd even go further and say this sho

Re: Web ID as passwordless authentication for debian web services

Hi again. Russ Allbery writes: > Jonas Smedegaard writes: >> Quoting Russ Allbery (2013-05-16 19:57:59) > >>> Sure, but if you have control over the server certificate and are tying >>> the server certificate to the user certificate via some mechanism like >>> Monkeysphere, why do the whole ind

Re: Do opaque struct changes break C library ABIs

Le vendredi 17 mai 2013 07:17:48, Guillem Jover a écrit : > (…) I agree dlopen()ing shared libraries in general should not > be supported (I'd even go further and say this should be outright > banned, given the pain it causes, and optional library support should > always be implemented by loading a

Re: Web ID as passwordless authentication for debian web services

Hi again. Russ Allbery writes: > I can understand why you may want to externalize the metadata if you have > no control over the certificate creation process and therefore can't put > metadata directly in it. I don't understand what you gain (other than > complexity) by externalizing the metada

Re: Web ID as passwordless authentication for debian web services

Russ Allbery writes: > Jonas Smedegaard writes: >> Quoting Russ Allbery (2013-05-16 18:37:06) > >>> but it's not clear to me why we'd bother as opposed to just issuing >>> client X.509 certificates with the metadata already included. > >> Because the very separation of identifiers from the ident

Re: Developer repositories for Debian

Hi. Sorry to be a bit late in the discussion. Russ Allbery 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 abl

Re: Web ID as passwordless authentication for debian web services

Quoting Stéphane Glondu (2013-05-17 08:14:13) > Le 16/05/2013 18:37, Russ Allbery a écrit : > >>> You could, in theory, switch to DNSSEC, but now you're just > >>> replacing one CA cartel with another. > > > >> Except that with DNSSEC (and DANE), the number of people you have > >> to trust is mu

Re: Web ID as passwordless authentication for debian web services [was: Re: Developer repositories for Debian]

Hi. Philip Hands 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

Re: Apport for Debian

Hi, On Fri, 17 May 2013, Ritesh Raj Sarraf wrote: > That is a good point. Thanks Thomas. We could submit apport reports with > the tag "Apport" and instruct reportbug to forward the report to > "pack...@qa.debian.org". > > This way we avoid the flood of bug reports in general while at the same >

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)

On Mon, 13 May 2013 02:31:02 +0200, m...@linux.it (Marco d'Itri) wrote: >Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev >depend on either upstart or systemd. >I would rather not be the one who will choose which one of them, so >I hope that we will get to a consensus abou