gmane.linux.debian.devel.general

Re: virtualbox moved to contrib

Antonio Terceiro — 2013-05-18T18:04:21

[re-adding the package maintainer(s) in Cc:, and adding the vagrant
maintainer(s) in the loop]

On Sat, May 18, 2013 at 05:49:38PM +0200, Adam Borowski wrote:

Indeed.

Two problems caused by this:

- if virtualbox stays in contrib, this will force vagrant to go to
  contrib as well (at least until we don't have alternative VM providers
  such as vagrant-kvm in main).

- users of unstable main that don't use contrib are now stuck with a
  buggy version of virtualbox (4.1.18-dfsg-2+deb7u1) whose kernel
  modules don't build against the default kernel version (3.8) ...


If that's possible, I would ask the virtualbox maintainer(s) to please
consider this alternative so that we can have virtualbox back in main.

Re: WebID as passwordless authentication for debian web services

Russ Allbery — 2013-05-18T17:37:35



Oh, absolutely.  For Debian, it makes the most sense to use PGP as the
basis for authentication since PGP is the official authentication
mechanism of the project and is quite strong.

Debian is almost uniquely positioned to use PGP for user authentication.
We have one of the best PGP-based authentication systems that I've ever
seen.  Most other organizations don't have anywhere near as well-developed
of a PGP trust model.


Yes.  WebID + PGP signatures on the metadata would be a way (secure so far
as I can tell) to associate X.509 certificates to PGP keys and use those
certificates for authentication.


I agree.

Re: Packaging releases without a tarball (sometimes)

Olivier Berger — 2013-05-18T17:25:16


Some interesting document to point them to, maybe :
http://wiki.debian.org/UpstreamGuide

My 2 cents,

Best regards,

Re: Web ID as passwordless authentication for debian web services

Olivier Berger — 2013-05-18T16:37:32


By decoupling the Identity descriptors (meta-data in the WebID
resources) from X509 certs (potentially generated localy and
self-signed), you may have several identifiers for a single auth token,
your TLS client cert.

This is one of the advantages of WebID that may be worth mentioning. The
fact that I'm in control of my identity (my WebID) is certainly key in a
world of delegated login systems relying on social network
operators. Debian (no more that FaceBook or my governement) doesn't have
to tell who I am, if I can write my own (master) profile with vi.
So Debian wouldn't need to issue certificates, if it trusts GPG signed
WebIDs, whereas other communities / employers / freedomboxes will have
other trust mechanisms, and you'll always use a single TLS cert to SSO
everywhere you want to be recognized.

Or maybe it's not that easy / beautiful ?

I tend to think that basing on a standard like RDF for meta-data
description also brings a lot of inherent interoperability compared of
kerberos, SAML or likes...

Re: WebID as passwordless authentication for debian web services

Olivier Berger — 2013-05-18T16:08:34

Hi.

Thanks for your valuable feedback.

Russ Allbery <rra< at >debian.org> writes:


ACK. For the records, I've forwarded your message to the webid list (see
[0]).

SNIP


We do verify such trust chains every day for db.debian.org AFAIU (and of
course for uploads)... so provided a GPG public key is in our keyrings,
it can be used to "certify" a WebID document, by verifying that it has
been signed by the correct GPG key, right ?

So, if I'm not trying to think too far of potential abuses, in pratical
terms, my understanding is that we may use WebID + TLS for Debian,
provided that we only trust FOAF/WebID documents signed with GPG by
Debian participants which would have been registered in a DB of ours as
allowing the use of a (remote) WebID, such registration being made with
the same GPG key's signature (for instance using the mail gateway of
db.debian.org).

Then such WebID could be trusted by Debian to provide meta-data about
the Debian project member, and could be used to authenticate to Debian
servers in a pas

Re: virtualbox moved to contrib

Adam Borowski — 2013-05-18T15:49:38


It's a major loss.

However, Watcom is needed only for 16-bit code, and VirtualBox has an EFI
mode.  Would it be possible to restrict it to EFI only in main, unless the
BIOS from contrib is loaded?

Re: virtualbox moved to contrib

Thomas Goirand — 2013-05-18T15:38:46

Thanks for highlighting it.
FYI, this has been discussed here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691148

Thomas

Re: Packaging releases without a tarball (sometimes)

Thomas Goirand — 2013-05-18T15:08:38

And if upstream doesn't do it after your request, you can
tag it yourself in your own (Alioth?) Git repository, then use
git archive to generate the tarball:

git tag 2.3.2 c2417972af1295be8dcc07470b0e3d25b0a77e0b
git archive --prefix=jplayer-2.3.2/ 2.3.2 | xz >../jplayer_2.3.2.orig.tar.xz

Note that you don't even need to store the master branch
in Alioth to do the above. It works as well if you only merge
upstream branch in your packaging branch, if you use the
following setup in debian/gbp.conf:

[DEFAULT]
debian-branch = debian/unstable
upstream-tag = %(version)s
compression = xz

Thomas

Bug#708776: ITP: moses -- statistical machine translation system

Koichi Akabe — 2013-05-18T14:58:08

Package: wnpp
Severity: wishlist
Owner: Koichi Akabe <vbkaisetsu< at >gmail.com>

* Package name    : moses
  Version         : 1.0
  Upstream Author : University of Edinburgh
* URL             : http://www.statmt.org/moses/
* License         : LGPL
  Programming Lang: C++
  Description     : statistical machine translation system

Moses is a statical machine translation system for any language pair which
you trained using a collection of parallel corpus. The translation algorithm
finds the highest probability translation among the exponential number of
choices.

virtualbox moved to contrib

Holger Levsen — 2013-05-18T12:30:37

Hi,

I've noticed that virtualbox moved from main to contrib (via 
http://jenkins.debian.net/job/chroot-installation_sid_install_full_desktop/) 
and while I personally don't use virtualbox anymore I think this is news to be 
announced (hence informing the publicity team), probably even deserving an 
entry in the jessie release notes.

For the jenkins test I will just install "virt-manager" instead.


cheers,
Holger

Re: jessie release goals

Andrei POPESCU — 2013-05-18T08:51:58

Probably a typo, fixed.

Kind regards,
Andrei

Re: jessie release goals

Vincent Lefevre — 2013-05-18T08:33:54

It says:

  An umask of 022 gives write permission to the other group members.

Is it true?

Re: Depends: libfoo:foreign ???

Neil Williams — 2013-05-18T07:58:07

On Sat, 18 May 2013 01:36:02 +0200
Adam Borowski <kilobyte< at >angband.pl> wrote:


Special casing which gets in the way as soon as people ask for armel on
armhf etc.

Multi-Arch is not just about runtime, there are very good reasons to
have foreign architectures installed together with Multi-Arch (armhf on
amd64) rather than just "related" architectures (i386 on amd64).

Cross-architecture dependencies are going to be necessary for other
packages (like sane Multi-Arch cross-compilers), not just Wine.

This isn't about just 32bit vs 64bit. The solution needs to be generic
for any combination of architectures.

Re: Web ID as passwordless authentication for debian web services

Wouter Verhelst — 2013-05-18T07:27:51

With the CA cartel, you're implicitly trusting some hundreds of
companies (most of whom you don't even know) to DTRT. With DNSSEC,
you're trusting the DNS root admins, the admins of your TLD and of any
intermediate domain that you depend on, and your registrar. I think
regardless of what your risk model is, "less people to trust apart from
myself" is *always* better than the alternative.

That doesn't mean it's perfect, and for some high-value targets anything
less than perfection is just not good enough. But that doesn't negate
the fact that one alternative outweighs the other.


Probably, yes. But if you're trying to defend against (possibly
malicious) governments, you've already lost. Nobody has the resources of
a government, and you just can't win there.

[...]

True.

I wasn't trying to imply that we should go for WebID, or any kind of
federated authentication scheme, for critical systems. "Federated" just
means "trust people to do whatever", which is a terrible idea whenever
one is trying to do real s

Re: Do opaque struct changes break C library ABIs

Wouter Verhelst — 2013-05-18T07:08:26

No. The return values of all your functions are still void* (or struct
foo*, where struct foo is not defined for the library user), which has
the exact same signature.


Yes. If you're going to support that, you need symbol versioning. This
is somewhat complicated, and I would recommend against it unless you
really need it.


If a program links your library statically in but loads plugins (one of
which might also load your library, but dynamically) you have the same
problem. However, doing something like that is a bad idea for multiple
reasons (including this one), so I wouldn't worry about it too much.


I'm pretty sure you're right.

Re: jessie release goals

Wouter Verhelst — 2013-05-18T06:51:02

There is a very wide gap between making things "hard to understand" and
making things simple enough so that "nearly anyone" can understand it...

I believe that the latter is at least as bad an idea as the former.

Re: Packaging releases without a tarball (sometimes)

Wouter Verhelst — 2013-05-18T06:58:35

Oh. my. god.

Just ask your upstream to do proper releases rather than manually
*pointing* to git commits? Really, this kind of behaviour is horrible,
and causing you all kinds of problems. I doubt you'll be the only one
who's having problems; people who install from source will have issues, too.

Git is a version control system, not a version release system.

Re: jessie release goals

Andrei POPESCU — 2013-05-18T06:49:30

Thanks, I just moved it under Debate.
 
Kind regards,
Andrei

Re: jessie release goals

Charles Plessy — 2013-05-18T05:55:46

Le Fri, May 17, 2013 at 08:29:42PM -0600, Bob Proulx a écrit :

See also:

    http://wiki.debian.org/umask

    http://wiki.debian.org/Debate

Cheers,

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

Francois Marier — 2013-05-18T05:20:45

I would argue that protecting user privacy is also relevant in the context
of being friendly to users ;)

log into whereas BrowserID is designed to prevent that. I don't know about
WebID.

Francois

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

Francois Marier — 2013-05-18T05:16:21

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/


Same here :)

Francois