Re: Bug#705169: RFH: iproute2 -- networking and traffic control tools

[Andreas Henriksson]

Hello Thomas!

On Wed, Apr 10, 2013 at 10:32:48PM +0200, Thomas Preud'homme wrote:
> Le mercredi 10 avril 2013 21:33:32, Andreas Henriksson a écrit :
[...]
> > "Please perform a full source scan and document all licensing information."
> > As requested by ftp-masters.
> 
> I didn't find a bug report mentionning this request. Is there a place
> mentionning it where progress to review the licensing could be posted?

There's nothing public about this. The only feedback is by the recent
reject of the later versions of the package from NEW (where it ended up
because of the package rename).
I've asked for additional details, but I wouldn't recommend holding
your breath until more info appears.

Please note the changes I've already done in the package git repo on
alioth collab-maint. More improvements are probably needed until
we reach a good enough state though.

> 
> I'm willing to help on this point. I might have some time this WE to start
> looking at it.

Thank you very much for your interest in helping out!

> 
> Best regards,
> 
> Thomas



-- 
Andreas Henriksson


signature.asc
Description: Digital signature

Re: Bug#705169: RFH: iproute2 -- networking and traffic control tools

[Andreas Henriksson]

Hello again!

Given the very positive response on my RFH I'm following up
with one more wish I forgot to mention.

If you are interested in learning more about the advanced networking
features provided by the linux kernel. Want to get into the gory details
and learn stuff that not many other people (who aren't kernel hackers)
know about. Why not take on the task to look at improving the
manpages for iproute2?
There are many bugs collected about pieces of information missing from
manpages in the debian bug tracker at http://bugs.debian.org/src:iproute

Start investigating, see what you find, try out stuff document
your results in the manpage for everyone else to enjoy!

-- 
Andreas Henriksson


-- 
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/20130411091421.ga28...@amd64.fatal.se

FPM in Debian archive [Was: Re: Bug#704686: ITP: ruby-arr-pm -- RPM reader and writer Ruby library]

[Laurent Bigonville]

> Jon Dowland wrote:
> >On Tue, Apr 09, 2013 at 05:33:20PM +0200, Laurent Bigonville wrote:
> >> This ruby gem is needed by FPM (see my ITP[0]).
> >
> >Hi Laurent, thanks for the clarification â?? to ask a related
> >question. What's the worth of FPM on Debian? Especially given the
> >issues that Wouter has raised in the bug¹
> >
> >¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;bug=688896
> 
> Quite, I'm concerned on that front too. Do we want to encourage or
> make it easier for people to use tools that don't care about our
> packaging policies?

I would confess that I'm mainly using it to create RPM's at work. For
some users it's easier (and faster) to use fpm than starting to dig into
a specfile or a debian package.

We already have checkinstall in the archive. The main difference here
with checkinstall is that fpm allows to package easily a complete tree,
I think that checkinstall requires some kind of 'make install' as it's
diverting some syscalls to track which files are installed. I know
nothing about the quality/policy compliance of the .deb generated by
checkinstall.

I've opened a bug on the upstream bug tracker about using dpkg instead
of ar/tar directly.

Cheers

Laurent Bigonville


--
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/2013045035.3eca8...@soldur.bigon.be

Bug#705206: ITP: compass-breakpoint-plugin -- really simple media queries with Sass

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: compass-breakpoint-plugin
  Version : 2.0.2
  Upstream Author : Mason Wendell , Sam Richard 

* URL : https://github.com/Team-Sass/breakpoint
* License : Expat or GPL-2
  Programming Lang: Sass
  Description : really simple media queries with Sass

 Compass is a CSS authoring framework which uses the Sass stylesheet
 language to make writing stylesheets powerful and easy.
 .
 Breakpoint makes writing media queries in Sass super simple. Create a
 variable using a simplified syntax based on most commonly used media
 queries, then call it using the `breakpoint` mixin.  Breakpoint handles
 all of the heavy lifting, from writing the media query itself, to
 handling cross-browser compatibility issues, so you can focus on what's
 important: making sure your website looks its best.
 .
 Breakpoint also allows you to get the context of your media queries
 from your code, allowing you to write dynamic mixins based on their
 media query context.
 .
 Additionally, Breakpoint includes Respond-To syntax for the semantic
 awesomeness of string names to identify your queries as opposed to
 variables, and for dynamically generating media queries.


-- 
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/20130411100415.7377.29490.report...@auryn.jones.dk

Re: Crypto export

[Alberto Fuentes]

On 04/11/2013 08:27 AM, Joerg Jaspert wrote:
> 
> https://ftp-master.debian.org/crypto-in-main/
> 
> Plus one mail for *every* NEW accepted package. Each and every time.
> Send to them.[1] See the dak git repo for the bxa stuff.
> 
> 
> [1] Nowadays only stored in a mailbox from us, at request from them, but
> available if requested.

Okay. *that* is crazy.

Crazy as in insane. Crazy as in coocoo

For so many reasons


-- 
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/51668c1c.3070...@qindel.com

Re: Crypto export

[Charles Plessy]

Le Thu, Apr 11, 2013 at 08:27:16AM +0200, Joerg Jaspert a écrit :
> 
> https://ftp-master.debian.org/crypto-in-main/
> 
> Plus one mail for *every* NEW accepted package. Each and every time.
> Send to them.[1] See the dak git repo for the bxa stuff.
> 
> 
> [1] Nowadays only stored in a mailbox from us, at request from them, but
> available if requested.

Hi Joerg,

since we are not sending the emails anymore, what would prevent us from
automatically adding to the mailbox one email per package entering the NEW
queue, and opening the contents of the NEW queue to the public ?

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20130411105615.gd17...@falafel.plessy.net

Bug#705212: ITP: chinese-checkers -- Multiplayer implementation of the chinese checkers game.

[Salvo Tomaselli]

Package: wnpp
Severity: wishlist
Owner: Salvo Tomaselli 

* Package name: chinese-checkers
  Version : 0.1
  Upstream Author : Many authors
* URL : https://github.com/ltworf/tin171
* License : GPL
  Programming Lang: Python, Erlang
  Description : Multiplayer implementation of the chinese checkers game.

It is an implementation of the chinese checkers game. It includes a server
capable of hosting multiple matches, a bot implemented to use multiple AI and
a GUI client to play against bots or other human players.


-- 
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/2013040238.18982.60303.reportbug@localhost

Bug#705221: ITP: pcapfix -- repair broken pcap files

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 

* Package name: pcapfix
  Version : 0.7.2
  Upstream Author : Robert Krause 
* URL : http://f00l.de/pcapfix
* License : GPL3
  Programming Lang: C
  Description : repair broken pcap files

 pcapfix tries to repair your broken pcap files fixing the global header and
 recovering the packets by searching and guessing the packet headers.
 .
 The tool first checks for an intact pcap global header and  repairs the all
 file if there are some corrupted bytes. It there seems to be no global header
 at all, pcapfix adds a self-created one at the beginning of the file. In a
 second step the tool tries to find pcap packet headers inside the file, below
 the global header. It checks if the values are correct (or seem to be
 correct) and tries to repair a packet if there is something wrong.
 .
 But, why? Sometimes your captured pcap files (from tcpdump, Wireshark or other)
 got cut off or are being corrupted in other ways. Although some captured the
 flag challenges deal with damaged pcap files periodically.
 .
 pcapfix will first step through the packets top down until it recognizes a
 corrupted one by using plausibility checks. After that the tool will brute
 force further pcap packet headers by reading the file byte by byte. If another
 proper packet is found, pcapfix restores the data in between by adding a
 well-formed pcap packet header.
 .
 Screenshot: http://f00l.de/pcapfix/pcapfix-0.4.png


-- 
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/20130411132626.6510.42898.reportbug@scutum.local

Re: FPM in Debian archive [Was: Re: Bug#704686: ITP: ruby-arr-pm -- RPM reader and writer Ruby library]

[Guillem Jover]

On Thu, 2013-04-11 at 11:50:35 +0200, Laurent Bigonville wrote:
> > Jon Dowland wrote:
> > >Hi Laurent, thanks for the clarification â?? to ask a related
> > >question. What's the worth of FPM on Debian? Especially given the
> > >issues that Wouter has raised in the bug¹
> > >
> > >¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;bug=688896
> > 
> > Quite, I'm concerned on that front too. Do we want to encourage or
> > make it easier for people to use tools that don't care about our
> > packaging policies?
> 
> I would confess that I'm mainly using it to create RPM's at work. For
> some users it's easier (and faster) to use fpm than starting to dig into
> a specfile or a debian package.
> 
> We already have checkinstall in the archive. The main difference here
> with checkinstall is that fpm allows to package easily a complete tree,
> I think that checkinstall requires some kind of 'make install' as it's
> diverting some syscalls to track which files are installed. I know
> nothing about the quality/policy compliance of the .deb generated by
> checkinstall.
> 
> I've opened a bug on the upstream bug tracker about using dpkg instead
> of ar/tar directly.

Well TBH, an upstream that's creating a program to package stuff that
cannot be bothered to read documentation about how stuff is done
properly (because "you don't have time for this crap" [0]), does not
inspire any confidence...

There's other problematic stuff though, like hardcoded shared library
dependencies w/o using dpkg-shlibdeps, or the injection of maintainer
scripts to add ldconfig calls, that I've spotted after a very quick
check.

[0]  (slides 17, 18)
 (section "The Solution - FPM")
Thanks to Wouter for pointing this out on debian-policy [1]
[1] 

Thanks,
Guillem


-- 
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/20130411135327.gb6...@gaara.hadrons.org

Debian two-factor auth, GSoC?

[Daniel Pocock]

Fedora recently put in Yubikey for their packagers[1], although they are
only half way there, supporting sudo but not web auth so far.

Similar things could probably happen in Debian.

I've proposed two-factor authentication as a potential area for a GSoC
project[2], two things come up:

a) would anyone else be interested in co-mentoring in this area (e.g.
development of tools to support/administer two factor auth)?

b) would anyone be interested in seeing this in Debian infrastructure,
has it been discussed before, and could this provide guidance to any
students proposing a project in this area?

Even if you don't have time to formally commit to GSoC, it would be
useful to have feedback from people who have experienced this in other
projects and would like to see it in Debian.


1. https://fedoraproject.org/wiki/Infrastructure/Yubikey


2.
http://wiki.debian.org/SummerOfCode2013/Projects#One-time-password_.28token.29_based_authentication_and_transactions


-- 
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/5166fca0.70...@pocock.com.au

Re: Debian two-factor auth, GSoC?

[Luca Filipozzi]

Hi,

DSA are already looking at two factor authentication, but TOTP based rather
than HOTP.  There are plenty of TOTP calculators that could be deployed on
smart phones, etc. rather than requiring DDs to own a YubiKey (and have USB
port available... i wonder if my iPad has a USB port...).

Interestingly, OpenSSH 6.2 (just released) now offers two-factor authentication
so we can augment ssh keys with TOTP.

Aslo, we have sso.debian.org, whose use we should expand.

I can help with a GSoC but I think DSA would prefer to lean in the direction of
the above.

Finally, if we are going to require DDs to have a physical object, I'm more in
favour of an OpenPGP token than an OTP token.  The OpenPGP token could then
power gpg (yes, Luca, we get that :) ) and act as an ssh-agent.  Couple that
with OTP, and we have quite strong overall solution, I think.

Let me know your thoughts,

Luca

On Thu, Apr 11, 2013 at 08:10:40PM +0200, Daniel Pocock wrote:
> 
> 
> Fedora recently put in Yubikey for their packagers[1], although they are
> only half way there, supporting sudo but not web auth so far.
> 
> Similar things could probably happen in Debian.
> 
> I've proposed two-factor authentication as a potential area for a GSoC
> project[2], two things come up:
> 
> a) would anyone else be interested in co-mentoring in this area (e.g.
> development of tools to support/administer two factor auth)?
> 
> b) would anyone be interested in seeing this in Debian infrastructure,
> has it been discussed before, and could this provide guidance to any
> students proposing a project in this area?
> 
> Even if you don't have time to formally commit to GSoC, it would be
> useful to have feedback from people who have experienced this in other
> projects and would like to see it in Debian.
> 
> 
> 1. https://fedoraproject.org/wiki/Infrastructure/Yubikey
> 
> 
> 2.
> http://wiki.debian.org/SummerOfCode2013/Projects#One-time-password_.28token.29_based_authentication_and_transactions
> 
> 
> -- 
> 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/5166fca0.70...@pocock.com.au
> 

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian


-- 
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/20130411190440.ga32...@emyr.net

Re: Debian two-factor auth, GSoC?

[Tollef Fog Heen]

]] Luca Filipozzi 

> I can help with a GSoC but I think DSA would prefer to lean in the direction 
> of
> the above.

I'm also happy to help with it.  I have a bit of experience with the
yubikey tokens, and at least one of the upstreams is on the path to
DDship, so I think we're reasonably well covered there.

> Finally, if we are going to require DDs to have a physical object, I'm more in
> favour of an OpenPGP token than an OTP token.  The OpenPGP token could then
> power gpg (yes, Luca, we get that :) ) and act as an ssh-agent.  Couple that
> with OTP, and we have quite strong overall solution, I think.

The Yubikey neo can run the java applet thingies, it seems, so it can
act as a GPG token too.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2a9p43m5t@rahvafeir.err.no

Re: Debian two-factor auth, GSoC?

[Paul Tagliamonte]

On Thu, Apr 11, 2013 at 09:25:02PM +0200, Tollef Fog Heen wrote:
> ]] Luca Filipozzi 
> 
> > I can help with a GSoC but I think DSA would prefer to lean in the 
> > direction of
> > the above.
> 
> I'm also happy to help with it.  I have a bit of experience with the
> yubikey tokens, and at least one of the upstreams is on the path to
> DDship, so I think we're reasonably well covered there.
> 
> > Finally, if we are going to require DDs to have a physical object, I'm more 
> > in
> > favour of an OpenPGP token than an OTP token.  The OpenPGP token could then
> > power gpg (yes, Luca, we get that :) ) and act as an ssh-agent.  Couple that
> > with OTP, and we have quite strong overall solution, I think.
> 
> The Yubikey neo can run the java applet thingies, it seems, so it can
> act as a GPG token too.

Completely unrelated to it's GSoC-eyness (which I would love to see,
quick, put it on the ideas page and put interested parties as mentors!),
I really hate the idea of "loosing" an unencrypted copy of my GPG
private half. I misplace everything, I don't need someone finding a copy
of my GPG key and abusing it :)

-T

-- 
 .''`.  Paul Tagliamonte 
: :'  : 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: Debian two-factor auth, GSoC?

[Daniel Pocock]

On 11/04/13 21:25, Tollef Fog Heen wrote:
> ]] Luca Filipozzi 
> 
>> I can help with a GSoC but I think DSA would prefer to lean in the direction 
>> of
>> the above.
> 
> I'm also happy to help with it.  I have a bit of experience with the
> yubikey tokens, and at least one of the upstreams is on the path to
> DDship, so I think we're reasonably well covered there.

Simon has actually asked me to review his Yubikey related packages, they
are on mentors already and any other reviews would be really helpful for
something like this:

http://mentors.debian.net/package/yubikey-ksm

http://mentors.debian.net/package/yubikey-val

>> Finally, if we are going to require DDs to have a physical object, I'm more 
>> in
>> favour of an OpenPGP token than an OTP token.  The OpenPGP token could then
>> power gpg (yes, Luca, we get that :) ) and act as an ssh-agent.  Couple that
>> with OTP, and we have quite strong overall solution, I think.
> 
> The Yubikey neo can run the java applet thingies, it seems, so it can
> act as a GPG token too.
> 

My dynalogin 0.9 packages in wheezy only support HOTP, but the 1.0
release (currently parked in experimental) supports TOTP too.  dynalogin
isn't really an algorithm itself, it is just a transport mechanism for
using this stuff within a distributed environment.  Underneath, it is
Simon's oath-toolkit library doing the algorithms.

As for the GSoC project, the packages mentioned on the wiki are just
examples and the scope is potentially quite broad


-- 
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/516710d5.8060...@pocock.com.au

Re: Debian two-factor auth, GSoC?

[Jonathan Dowland]

On Thu, Apr 11, 2013 at 07:04:40PM +, Luca Filipozzi wrote:
> Aslo, we have sso.debian.org, whose use we should expand.

I'd love to see that.


-- 
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/20130411194818.GA21214@debian

Re: Debian two-factor auth, GSoC?

[Martin Zobel-Helas]

Hi, 

> Aslo, we have sso.debian.org, whose use we should expand.

DACS (http://dacs.dss.ca) the software behind sso.debian.org also
support one-time passwords [1].  I had no time yet to setup anything
regarding this, but I welcome help.

Cheers,
Martin

[1] http://dacs.dss.ca/man/dacstoken.1.html
-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


-- 
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/20130411200817.gb19...@ftbfs.de

Re: Debian two-factor auth, GSoC?

[Luca Filipozzi]

On Thu, Apr 11, 2013 at 03:35:35PM -0400, Paul Tagliamonte wrote:
> I really hate the idea of "loosing" an unencrypted copy of my GPG
> private half. I misplace everything, I don't need someone finding a copy
> of my GPG key and abusing it :)

You write the private key to the token.  You can't read it back.

You then send stuff through the token to be encrypted / signed.

And you still need your passphrase.

At least that's how I understand it.

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian


-- 
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/20130411203919.ga2...@emyr.net

Re: Debian two-factor auth, GSoC?

[Lisandro Damián Nicanor Pérez Meyer]

On Thu 11 Apr 2013 16:04:40 Luca Filipozzi escribió:
[snip]
> Finally, if we are going to require DDs to have a physical object

Then the project would possibly start loosing contributors like me, who have 
lots of problems with customs and getting dollars, specially if it's about 
technological stuff. And then let's talk about taxes...

In other words: -1 from me.

-- 
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself.  Therefore all
progress depends on the unreasonable man.
  George Bernard Shaw

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Debian two-factor auth, GSoC?

[Martin Zobel-Helas]

Hi, 

On Thu Apr 11, 2013 at 19:04:24 -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Thu 11 Apr 2013 16:04:40 Luca Filipozzi escribió:
> [snip]
> > Finally, if we are going to require DDs to have a physical object
 ^^
 ||
 
> In other words: -1 from me.

I read Luca's 'if' here as 'if, at all'

-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


-- 
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/20130411222940.gc19...@ftbfs.de

Work-needing packages report for Apr 12, 2013

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 513 (new: 10)
Total number of packages offered up for adoption: 147 (new: 2)
Total number of packages requested help for: 65 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   ditz (#705149), orphaned yesterday
 Description: distributed issue tracker
 Installations reported by Popcon: 81

   freedict (#704967), orphaned 3 days ago
 Description: Dict package for Afrikaans-German Freedict dictionary
 Installations reported by Popcon: 421

   ispell-lt (#704968), orphaned 3 days ago
 Description: ispell dictionary for Lithuanian (LT)
 Installations reported by Popcon: 2891

   liboauth-php (#705150), orphaned yesterday
 Description: PHP library implementing the OAuth secure
   authentication protocol
 Installations reported by Popcon: 64

   libuninameslist (#704969), orphaned 3 days ago
 Description: a library of Unicode annotation data (development
   files)
 Installations reported by Popcon: 2084

   mcs (#705095), orphaned yesterday
 Description: abstraction library to store configuration settings
 Installations reported by Popcon: 3937

   opendict (#704970), orphaned 3 days ago
 Description: computer dictionary for several dictionary formats
 Installations reported by Popcon: 253

   pyblosxom (#705151), orphaned yesterday
 Description: a lightweight file-based weblog system
 Installations reported by Popcon: 58

   pylibtiff (#705208), orphaned today
 Installations reported by Popcon: 15

   pythonqt (#705207), orphaned today
 Installations reported by Popcon: 20

503 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   aafigure (#704925), offered 4 days ago
 Description: ASCII art to image converter
 Installations reported by Popcon: 54

   testng (#705103), offered yesterday
 Description: testing framework for Java
 Installations reported by Popcon: 196

145 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] iproute2 (#705169), requested yesterday
 Description: networking and traffic control tools

   apt-file (#703366), requested 24 days ago
 Description: search for files within Debian packages (command-line
   interface)
 Installations reported by Popcon: 13466

   apt-xapian-index (#567955), requested 1165 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 64549

   asymptote (#517342), requested 1504 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 4204

   athcool (#278442), requested 3089 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 61

   balsa (#642906), requested 564 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 807

   bastille (#592137), requested 978 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 168

   cardstories (#624100), requested 717 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 7

   chromium-browser (#583826), requested 1047 days ago
 Description: Chromium browser
 Installations reported by Popcon: 13430

   cups (#532097), requested 1405 days ago
 Description: Common UNIX Printing System
 Installations reported by Popcon: 108133

   debtags (#567954), requested 1165 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2460

   doc-central (#566364), requested 1174 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 207

   fbcat (#565156), requested 1184 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 149

   flightgear (#487388), requested 1755 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 779

   freeipmi (#628062), requested 686 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 2399

   gnat-4.4 (#539633), requested 1822 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 I

Bug#705256: ITP: libparallel-runner-perl -- Perl module to manage running things in parallel processes

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: libparallel-runner-perl
  Version : 0.012
  Upstream Author : Chad Granum 
* URL : https://metacpan.org/release/Fennec
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to manage running things in parallel processes

There are several other modules to do this, you probably want one of
them. This module exists as a super specialised parallel task manager.
You create the object with a proces limit and callbacks for what to do
while waiting for a free process slot, as well as a callback for what a
process shoudl do just before exiting.

You must explicetly call $runner->finish() when you are done. If the
runner is destroyed before it's children are finished a warning will be
generated and your child processes will be killed, by force if
necessary.

If you specify a maximum of 1 then no forking will occur, and run() will
block until the coderef returns. You can force a fork by providing a
boolean true value as the second argument to run(), this will force the
runner to fork before running the coderef, however run() will still
block until it the child exits.


-- 
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/20130412042731.19045.90556.reportbug@localhost

Re: Debian two-factor auth, GSoC?

[Thomas Goirand]

On 04/12/2013 03:25 AM, Tollef Fog Heen wrote:
> The Yubikey neo can run the java applet thingies, it seems, so it can
> act as a GPG token too. 
Please, please, please ... no java!!!
That's a security nightmare. I think we'd be less safe with
than without it.

Also, while I think the idea is nice, and that it would be a nice
thing to *propose* it to all DDs, I think it would be annoying
to actually *require* 2 factors auth from DDs (especially with
the ssh keys on Alioth).

Thomas


-- 
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/5167a1f7.9070...@debian.org

Re: Debian two-factor auth, GSoC?

[Daniel Pocock]

On 12/04/13 07:56, Thomas Goirand wrote:
> On 04/12/2013 03:25 AM, Tollef Fog Heen wrote:
>> The Yubikey neo can run the java applet thingies, it seems, so it can
>> act as a GPG token too. 
> Please, please, please ... no java!!!
> That's a security nightmare. I think we'd be less safe with
> than without it.
> 
> Also, while I think the idea is nice, and that it would be a nice
> thing to *propose* it to all DDs, I think it would be annoying
> to actually *require* 2 factors auth from DDs (especially with
> the ssh keys on Alioth).
> 

There was never any suggestion to make something mandatory, I actually
agree with those concerns

Given the nature of Debian, it would be a personalised solution

So, if a DD regularly accesses Debian infrastructure from a PC that he
does not control (e.g. a work PC) he can choose to use TOTP instead of a
password.  A DD who always uses a personal laptop may prefer to use an
ssh key.  It is all about choice.

With the right tools, DDs would have these choices each time they log
in, or any one person can choose to make *OTP mandatory for their own login.

So any potential GSoC project may involve making tools that allow DDs to
set this up, the way they want, quickly - but only if they want it.


-- 
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/5167a297.4090...@pocock.com.au

Re: Debian two-factor auth, GSoC?

[Tollef Fog Heen]

]] Thomas Goirand 

> On 04/12/2013 03:25 AM, Tollef Fog Heen wrote:
> > The Yubikey neo can run the java applet thingies, it seems, so it can
> > act as a GPG token too. 
> Please, please, please ... no java!!!
> That's a security nightmare. I think we'd be less safe with
> than without it.

Please take your FUD elsewhere.

It's an implementation of the JavaCard specification.  It's not
something that runs in your web browser, but they're both called
applets.

> Also, while I think the idea is nice, and that it would be a nice
> thing to *propose* it to all DDs, I think it would be annoying
> to actually *require* 2 factors auth from DDs (especially with
> the ssh keys on Alioth).

We're unlikely to require it for all DDs.  We are likely to require it
for access to certain important hosts, but this shouldn't affect many
people.  Most likely just DSA.

(Alioth isn't part of the Debian infrastructure in this context, so I'm
not sure why you're mentioning it.)

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obdkfe4x@qurzaw.varnish-software.com

Re: Debian two-factor auth, GSoC?

[Russ Allbery]

Thomas Goirand  writes:
> On 04/12/2013 03:25 AM, Tollef Fog Heen wrote:

>> The Yubikey neo can run the java applet thingies, it seems, so it can
>> act as a GPG token too.

> Please, please, please ... no java!!!  That's a security nightmare. I
> think we'd be less safe with than without it.

You do realize that most of the Java vulnerabilities are vulnerabilities
in the sandboxing model and therefore are only particularly interesting
when you're downloading random untrustsed Java programs from the Internet
and running them in the sandbox in your web browser, right?

Those aren't flaws in the *language*.

Sandboxing programming languages is very difficult; most languages don't
even attempt it.  Perl used to have a sandboxing module and gave up on it
because it was too hard, thus making it even less secure than Java in that
specific respect, but no one calls it a security nightmare.

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


-- 
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/8738uws0ow@windlord.stanford.edu

Re: Debian two-factor auth, GSoC?

[Don Armstrong]

On Thu, 11 Apr 2013, Russ Allbery wrote:
> Sandboxing programming languages is very difficult; most languages
> don't even attempt it. Perl used to have a sandboxing module and
> gave up on it because it was too hard, thus making it even less
> secure than Java in that specific respect, but no one calls it a
> security nightmare.

It still exists; it's called Safe. It works fairly well, but it's
really hard to balance actually being able to execute code that does
anything useful with maintaining security.


Don Armstrong

-- 
I'd never hurt another living thing.
But if I did...
It would be you.
 -- Chris Bishop  http://www.chrisbishop.com/her/archives/her69.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20130412065537.gc15...@teltox.donarmstrong.com