Re: Discarding uploaded binary packages

[Joerg Jaspert]

On 13001 March 1977, Michael Gilbert wrote:

> So, are we ready to do this?

No.
Its for after wheezy, definitely.
Also, there are some open issues to be solved for this to happen.
The most important is being able to deal with arch all packages. And
worse - arch all packages able to build only on certain architectures.
But thats outside dak and my area. Goto the buildd/wanna-build people to
help for that.

Adjusting dak then to throw away stuff and only allow buildd keys to
have .debs pass through isn't all that hard.

-- 
bye, Joerg
* libpng2 no libpng3 no why ? because no yes no yes no yes bullshit no yes
  no yes no yes stop ? no when someday beep beep beep beep (Closes: #157011)
 -- Christian Marillat   Thu, 29 Aug 2002 16:41:58 +0200


-- 
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/87obk1wpqf@gkar.ganneff.de

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Dmitrijs Ledkovs]

On 17 October 2012 03:05, John Paul Adrian Glaubitz
 wrote:
> On Oct 17, 2012, at 1:03 AM, Barry Warsaw  wrote:
>
>> On Oct 12, 2012, at 02:22 PM, Benjamin Drung wrote:
>>
>>> How does bzr-builddeb depend on Launchpad? bzr is integrated into
>>> Launchpad, but you can use bzr without Launchpad as every other DVCS.
>>
>> $ bzr branch debianlp:mypackage
>>
>> is one way to use Launchpad with bzr for Debian effectively.  It's certainly
>> not *required*, but often works out pretty nicely.
>
> And how do I use bzr *without* Launchpad when I don't want to?
>
> I'm not against LP per se, but I don't like tools limiting my choices in 
> development that way.
>
> Adrian

Here is documentation on using bzr *without* Launchpad specifically
for packaging:
http://jameswestby.net/bzr/builddeb/user_manual/

Note that none of the tutorial has launchpad in it.

There is one place where it offers you to merge upstream bzr branch +
with pristine-tar delta on top, but that is optional.

Regards,

Dmitrijs.


-- 
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/canbhlugrwejfdei+xcach+2p3thnbk7eis3pmkigju6bovq...@mail.gmail.com

Bug#690742: ITP: djabberd -- Distributed Jabber server

[Ioan Rogers]

Package: wnpp
Owner: Martin Atkins 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,
debian-p...@lists.debian.org

* Package name: djabberd
  Version : 0.85-2
  Upstream Author : Debian Perl Group

* URL : http://danga.com/djabberd
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Distributed Jabber server

djabberd is a high-performance, scalable, extensible Jabber/XMPP
server framework. While it comes with an example server, it's
really a set of classes for you to build your own Jabber server
without understanding Jabber. Instead of working with XML and
protocol-specific details, you subclass parts and work with sane
objects and data structures and let DJabberd do all the ugly work.



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

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Paul Tagliamonte]

On Wed, Oct 17, 2012 at 04:05:10AM +0200, John Paul Adrian Glaubitz wrote:
> On Oct 17, 2012, at 1:03 AM, Barry Warsaw  wrote:
> 
> > On Oct 12, 2012, at 02:22 PM, Benjamin Drung wrote:
> > 
> >> How does bzr-builddeb depend on Launchpad? bzr is integrated into
> >> Launchpad, but you can use bzr without Launchpad as every other DVCS.
> > 
> > $ bzr branch debianlp:mypackage
> > 
> > is one way to use Launchpad with bzr for Debian effectively.  It's certainly
> > not *required*, but often works out pretty nicely.
> 
> And how do I use bzr *without* Launchpad when I don't want to?

man bzr -- look for "bzr init-repository LOCATION"

> 
> I'm not against LP per se, but I don't like tools limiting my choices in 
> development that way.

You know we have bzr.d.o? - http://anonscm.debian.org/bzr/

> 
> Adrian
> 
> --
> 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/bc4bd80d-1d13-4c4f-bf61-060e5d651...@physik.fu-berlin.de
> 

HTH.

Cheery-bye,
  Paul

-- 
 .''`.  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: Poll (was: Popularity of bzr-builddeb and dh-make)

[John Paul Adrian Glaubitz]

On Oct 17, 2012, at 1:03 AM, Barry Warsaw  wrote:

> On Oct 12, 2012, at 02:22 PM, Benjamin Drung wrote:
> 
>> How does bzr-builddeb depend on Launchpad? bzr is integrated into
>> Launchpad, but you can use bzr without Launchpad as every other DVCS.
> 
> $ bzr branch debianlp:mypackage
> 
> is one way to use Launchpad with bzr for Debian effectively.  It's certainly
> not *required*, but often works out pretty nicely.

And how do I use bzr *without* Launchpad when I don't want to?

I'm not against LP per se, but I don't like tools limiting my choices in 
development that way.

Adrian

--
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/bc4bd80d-1d13-4c4f-bf61-060e5d651...@physik.fu-berlin.de

Re: Discarding uploaded binary packages

[Chow Loong Jin]

On 17/10/2012 08:36, Russell Coker wrote:
> On Wed, 17 Oct 2012, Barry Warsaw  wrote:
>> I also think allowing source-only uploads makes for easier contributions,
>> and thus hopefully more contributions.
> 
> Why would it be easier?  Surely we still want people to build packages first 
> to 
> ensure that we don't needlessly get FTBFS bugs.

Because binary packages are big, and uploading them reliably from a region with
crappy internet access sucks, especially when trying to upload them over SFTP.
Honestly, if we're not going to be using these, why upload them? It's a
pointless waste of bandwidth.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: Discarding uploaded binary packages

[Russell Coker]

On Wed, 17 Oct 2012, Barry Warsaw  wrote:
> I also think allowing source-only uploads makes for easier contributions,
> and thus hopefully more contributions.

Why would it be easier?  Surely we still want people to build packages first to 
ensure that we don't needlessly get FTBFS bugs.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201210171136.24758.russ...@coker.com.au

Bug#690738: ITP: wavegain -- replaygain for WAV files

[Rodrigo Silva]

Package: wnpp
Severity: wishlist
Owner: Rodrigo Silva 

* Package name: wavegain
  Version : 1.3.1
  Upstream Author : John Edwards 
* URL : http://www.rarewares.org/others.php
* License : LGP-2.1+
  Programming Lang: C
  Description : replaygain for WAV files
 WaveGain is an application of the ReplayGain algorithms to standard PCM wave
 files. Calculated gain adjustments are applied directly to the audio data,
 instead of just writing metadata as traditionally done for other formats
 like MP3, FLAC and Ogg Vorbis.
 .
 Replaygain is a standard that allows compatible players to play audio files
 with an adjusted volume gain so they have a consistent perceived loudness.
 .
 Loudness can be averaged either for each individual file, also called "Track"
 or "Radio" mode, where every song is adjusted to the same standard loudness;
or
 by group, also called "Album" mode, where individual "songs" may sound louder
 or quieter than others, but each "album" as a whole has the same average
 loudness as other albums.
 .
 For more information,
 
 


-- 
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/20121017001922.5828.60599.reportbug@desktop

Re: Discarding uploaded binary packages

[Barry Warsaw]

On Oct 16, 2012, at 03:54 PM, Tollef Fog Heen wrote:

>]] Jakub Wilk 
>
>> What makes a buildd more secure than a machine of J. Random Developer?
>
>It has a smaller attack surface due to few users, firewalls, few
>packages installed, nobody using it for browsing the web, etc.

I also think allowing source-only uploads makes for easier contributions, and
thus hopefully *more* contributions.

Cheers,
-Barry


signature.asc
Description: PGP signature

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Barry Warsaw]

On Oct 12, 2012, at 02:22 PM, Benjamin Drung wrote:

>How does bzr-builddeb depend on Launchpad? bzr is integrated into
>Launchpad, but you can use bzr without Launchpad as every other DVCS.

$ bzr branch debianlp:mypackage

is one way to use Launchpad with bzr for Debian effectively.  It's certainly
not *required*, but often works out pretty nicely.

Cheers,
-Barry


signature.asc
Description: PGP signature

Re: Poll (was: Popularity of bzr-builddeb and dh-make)

[Barry Warsaw]

On Oct 12, 2012, at 09:13 PM, Hideki Yamane wrote:

> bzr-builddeb is, well, it seems that is useful in UDD (Ubuntu Distributed
> Development, as Ubuntu packaging guide says) way, but now it heavily relies
> on Launchpad in my point of view. And, packaging-dev can specify
> vendor-specific Recommends/Suggest in its rules, then use it for Ubuntu is
> meaningful.
>
> (Well, LP is quite nice and Debian should consider to introduce its good
> point (user friendly web interface, etc), but I don't want to depend on it,
> sorry).

Now, clearly I am biased, but I generally use bzr-builddeb even when
developing changes targeted directly for Debian, because I really like the
workflow and much prefer bzr over the alternatives.  When the Launchpad
importer is up-to-date for a particular Debian package[*], everything works
nicely and quickly, and I've even managed to make quilt work mostly
non-painfully.

I accept that others have different, completely valid opinions on the matter.

-Barry

[*] which is actually more likely with Debian branches than Ubuntu branches
because Ubuntu developers will almost never push to debianlp: branches.


signature.asc
Description: PGP signature

Report from the BSP in Utrecht, NL

[Paul Gevers]

Next to Alcester, also a BSP was held in Utrecht, the Netherlands [1].

In total, over two days, we worked with 17 people on a number of bugs:
* 15 RC bugs were fixed or otherwise dramatically improved
*  7 RC bugs were marked notfound in stable and already fixed in wheezy
* 18 release-notes bugs were closed
*  6 debconf translations were created/updated
* a lot more bugs where touched.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Report from the BSP in Alcester, GB

[Jon Dowland]

Great work, thanks all!

Did you usertag any of the bugs you closed in that party? It would be kind-of
interesting to see them. Does anyone else think that might be useful (either
now or in future?) I suppose I could just scan debian-bugs-dist for the time
period.


-- 
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/20121016155155.GC30695@debian

Bug#690693: ITP: thin-provisioning-tools -- Tools to manage thinly provisioned volume metadata in LVM

[Neil Wilson]

Package: wnpp
Severity: wishlist
Owner: Neil Wilson 

* Package name: thin-provisioning-tools
  Version : 0.1.5
  Upstream Author : Red Hat, Inc.
* URL : https://github.com/jthornber/thin-provisioning-tools
* License : GPL v3
  Programming Lang: C++
  Description : Tools to manage thinly provisioned volume metadata in LVM

Installs check, dump and restore tools that manage the thin volume
metadata in the thin provisioning pool. 


-- 
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/20121016153805.7776.58024.reportbug@srv-7tih9.localdomain

Re: Discarding uploaded binary packages

[Gergely Nagy]

Tollef Fog Heen  writes:

> ]] Jakub Wilk 
>
>> What makes a buildd more secure than a machine of J. Random Developer?
>
> It has a smaller attack surface due to few users, firewalls, few
> packages installed, nobody using it for browsing the web, etc.

We seem to be forgetting, that the real advantage of source-only uploads
isn't necessarily security, but a controlled build environment on *all*
architectures.

There is sbuild, pbuilder and the rest, but there are still packages
uploaded that are built in an unclean environment, thereby becoming
broken in various interesting ways.

Nevermind security, whether N buildds are more secure than 200N random
systems scattered around the world - a controlled environment makes
source-only uploads a win, without doubt.

(Of course, there's the corner case of bootstrapping things, but that's
a corner case, and should be handled as such, not as the norm.)

-- 
|8]


-- 
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/87r4oy335m.fsf@algernon.balabit

Re: Discarding uploaded binary packages

[Tollef Fog Heen]

]] Jakub Wilk 

> What makes a buildd more secure than a machine of J. Random Developer?

It has a smaller attack surface due to few users, firewalls, few
packages installed, nobody using it for browsing the web, etc.

-- 
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/87txtuplni@xoog.err.no

Re: Discarding uploaded binary packages

[Russell Coker]

On Tue, 16 Oct 2012, Arno Töll  wrote:
> On 16.10.2012 14:00, Russell Coker wrote:
> > There are a fairly small number of Debian servers.  So even if the
> > probability of system compromise for a Debian server was the same as for
> > a laptop owned by a random DD the fact that DD workstations outnumber
> > Debian servers by at least 200:1 makes them more of a risk.
> 
> Not a strong argument. The impact of a compromise of a buildd [or J
> Random Developer's machine running the buildd] is substantially higher
> given the compromise would affect 30k source packages, as opposed to [1,
> $whatever_gregoa_maintains_today[ of packages distributed amongst 950+
> individual machines.

An attacker wouldn't want to compromise all 30K packages, that would increase 
the risk of detection without increasing the benefit.  They would want to 
compromise a very small number of relatively common packages.  For example 
they could compromise Apache or a library it depends on, some library that is 
used by both KDE and GNOME, dash, bash, or a library used by shells.

Compromising 100% of systems with a high probability of detection would be a 
lot less useful than compromising 50% with a low probability of detection.

So compromising the workstation of a random DD who packages only some programs 
that aren't particularly popular wouldn't be a very effective attack in the 
short term.  But using such an attack to target other DDs would be easier than 
using it to target build servers.  For example an attacker who compromised a 
single program could file a bug report saying that it gave a SEGV when run 
with a new version of a particular library and have a good chance that the 
maintainer of the library would do a test...

> Moreover, if you go down that path, you do not win anything of the state
> being, as an attacker can still make a sourceful upload which enters the
> archive unaudited as well.

The advantage for the good people is that source can be audited.  While it is 
difficult to audit source it's possible without huge effort, particularly as 
the changes made in the process of Debian packaging are generally small when 
compared to the upstream source.

Currently we have no certainty of the version of the libraries and compiler 
used for building a package.  So if a package has a different binary when it's 
rebuilt that isn't evidence of attack.  Determining what parts of the binary 
change might be due to actual differences in operation of the program as 
opposed to the same logic with different compilation is going to take some 
work.

Comparing two different versions of a Debian package at the source level to 
determine if the changes appear to match the changelog shouldn't be THAT 
difficult.  Comparing two different binaries is going to be a lot harder.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


--
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/201210170023.43896.russ...@coker.com.au

Re: Discarding uploaded binary packages

[Arno Töll]

Hi,

On 16.10.2012 14:00, Russell Coker wrote:
> There are a fairly small number of Debian servers.  So even if the 
> probability 
> of system compromise for a Debian server was the same as for a laptop owned 
> by 
> a random DD the fact that DD workstations outnumber Debian servers by at 
> least 
> 200:1 makes them more of a risk.

Not a strong argument. The impact of a compromise of a buildd [or J
Random Developer's machine running the buildd] is substantially higher
given the compromise would affect 30k source packages, as opposed to [1,
$whatever_gregoa_maintains_today[ of packages distributed amongst 950+
individual machines.

Moreover, if you go down that path, you do not win anything of the state
being, as an attacker can still make a sourceful upload which enters the
archive unaudited as well.

Not to say, throwing away binary packages would be a bad idea though. We
just need someone to care enough to implement missing bits and find a
way how to deal with arch:all.



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Discarding uploaded binary packages

[Russell Coker]

On Tue, 16 Oct 2012, Jakub Wilk  wrote:
> * martin f krafft , 2012-10-16, 08:21:
> >>This is my opinion but I admit I have not followed previous
> >>discussions on the subject
> >
> >http://lists.debian.org/debian-security/2004/09/msg00014.html
> >
> >We have not cared enough for almost 20 years that 9 out of 10 binary
> >packages in use (i386 until 2005, amd64 since then) are built on
> >machines that are individually maintained according to widely varying
> >security standards to do anything about it, AFAICT.
> 
> What makes a buildd more secure than a machine of J. Random Developer?
> I'm honestly curious.

I believe that the sysadmin skill of the people who run the build servers is 
greater than that of most DDs.

The Debian servers are run in relatively secure environments as opposed to DD 
workstations being laptops that are often stored in hotel rooms and other 
fairly insecure environments.

There are a fairly small number of Debian servers.  So even if the probability 
of system compromise for a Debian server was the same as for a laptop owned by 
a random DD the fact that DD workstations outnumber Debian servers by at least 
200:1 makes them more of a risk.


One final think to note is that if an attacker manages to compromise a Debian 
server they will probably start by compromising the workstation used by a 
random DD.  So I don't think that the case of a compromised server with 
thousands of secure workstations is a case to prepare for, but the case of 
compromised workstation(s) before a compromised server is one to prepare for.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201210162300.31295.russ...@coker.com.au

Re: Discarding uploaded binary packages

[Jakub Wilk]

* martin f krafft , 2012-10-16, 08:21:
This is my opinion but I admit I have not followed previous 
discussions on the subject


http://lists.debian.org/debian-security/2004/09/msg00014.html

We have not cared enough for almost 20 years that 9 out of 10 binary 
packages in use (i386 until 2005, amd64 since then) are built on 
machines that are individually maintained according to widely varying 
security standards to do anything about it, AFAICT.


What makes a buildd more secure than a machine of J. Random Developer? 
I'm honestly curious.


--
Jakub Wilk


--
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/20121016110123.ga6...@jwilk.net

Bug#690673: ITP: ruby-integration -- Ruby library for numerical integration

[Cédric Boutillier]

Package: wnpp
Severity: wishlist
Owner: "Cédric Boutillier" 

* Package name: ruby-integration
  Version : 0.1.0
  Upstream Author : Ben Gimpert, Claudio Bustos
* URL : https://github.com/clbustos/integration 
* License : MIT/X
  Programming Lang: Ruby
  Description : Ruby library for numerical integration

This library offers numerical integration for Ruby, with a simple
interface. The rectangular, trapezoidal, Simpson, adaptive
quadrature, Monte Carlo and Romberg integration methods are available
in pure Ruby. Better performance and support for infinite bounds can be
obtained via Ruby/GSL (from the ruby-gsl package).

Cheers,

Cédric


signature.asc
Description: Digital signature

Re: Discarding uploaded binary packages

[martin f krafft]

also sprach Holger Levsen  [2012.10.16.0945 +0200]:
> > We have not cared enough for almost 20 years that 9 out of 10 binary
> > packages in use (i386 until 2005, amd64 since then) are built on
> > machines that are individually maintained according to widely
> > varying security standards to do anything about it, AFAICT.
> 
> your point being?

That our users don't seem to care, and that probably is why we
haven't done anything about it.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"there's someone in my head but it's not me."
-- pink floyd, the dark side of the moon, 1972


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Discarding uploaded binary packages

[Stefano Zacchiroli]

On Mon, Oct 15, 2012 at 10:59:27PM -0400, Michael Gilbert wrote:
> I know this subject has been discussed on and off in the past, but
> there's new evidence that it's simply the right thing to do.

Nice, although it's not new evidence we need :). The state of last
discussion on the matter is that there is consensus in going ahead, here
are a couple of pointers:

- https://lists.debian.org/debian-devel/2011/04/msg00840.html
- https://lists.debian.org/debian-devel-announce/2011/06/msg0.html

> So, are we ready to do this?

Sure, where are your dak patches implementing it? :)

Note: I don't want to smash down the discussion with a lame "show me the
code" argument. But I do want to avoid the impression that "we're unable
to decide" when I fact, in this case, we are and we did. But that's,
unfortunately, not enough to make appear out of thin area the code
implementing the decision.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
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

Re: Discarding uploaded binary packages

[Holger Levsen]

Hi,

On Dienstag, 16. Oktober 2012, martin f krafft wrote:
> We have not cared enough for almost 20 years that 9 out of 10 binary
> packages in use (i386 until 2005, amd64 since then) are built on
> machines that are individually maintained according to widely
> varying security standards to do anything about it, AFAICT.

your point being?

(And obviously, +1 to the suggestion at hand.)


cheers,
Holger


-- 
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/201210160945.58694.hol...@layer-acht.org