Re: [RFC] Collecting changelog entries in projectb

2010-02-28 Thread Wouter Verhelst
On Fri, Feb 26, 2010 at 12:58:18PM +, Simon McVittie wrote:
 hello (6.6-1) unstable; urgency=low
 
  * New upstream release.
- Fixes a buffer overflow in excessively long greetings (CVE-2038-001)
 
  -- Simon McVittie s...@debian.org  Tue, April 1, 2038 09:00:00 +
 
 (I conjecture that by 2038, Debian will run on toasters, GNU hello will
 be security-sensitive, and we'll still be fixing buffer overflows...)

... and that there will be little, if any, security issues in 2038,
judging by the CVE number you chose ;-P

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100228105834.gz31...@celtic.nixsys.be



Re: [RFC] Collecting changelog entries in projectb

2010-02-26 Thread Philipp Kern
On 2010-02-26, Charles Plessy ple...@debian.org wrote:
 If the developments on changelog parsing introduce new requirements, in
 particular limitations on post-upload corrections, I strongly recommend to
 document this in our Policy.

Post-upload corrections?

Kind regards,
Philipp Kern


-- 
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/slrnhofbl4.9b7.tr...@kelgar.0x539.de



Re: [RFC] Collecting changelog entries in projectb

2010-02-26 Thread Simon McVittie
On Fri, 26 Feb 2010 at 11:21:08 +, Philipp Kern wrote:
 Post-upload corrections?

I assume Charles refers to this practice: imagine I maintained hello, and
uploaded upstream release 6.6 without initially realising that it contained
a security fix:

hello (6.6-1) unstable; urgency=low

 * New upstream release.

 -- Simon McVittie s...@debian.org  Tue, April 1, 2038 09:00:00 +

Then in a later upload, I'd want to correct that:

hello (6.6-2) unstable; urgency=medium

 * Add patch from upstream to fix build on knetbsd-mipsel and
   knetbsd-toaster (Closes: #66)
 * Retroactively note CVE number for 6.6-1

 -- Simon McVittie s...@debian.org  Wed, April 2, 2038 09:00:00 +

hello (6.6-1) unstable; urgency=low

 * New upstream release.
   - Fixes a buffer overflow in excessively long greetings (CVE-2038-001)

 -- Simon McVittie s...@debian.org  Tue, April 1, 2038 09:00:00 +

(I conjecture that by 2038, Debian will run on toasters, GNU hello will
be security-sensitive, and we'll still be fixing buffer overflows...)

S


-- 
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/20100226125818.ga7...@reptile.pseudorandom.co.uk



Re: [RFC] Collecting changelog entries in projectb

2010-02-26 Thread Jon Dowland
On Wed, Feb 24, 2010 at 08:25:37PM +0100, Lucas Nussbaum
wrote:
  UDD is the wrong approach. And also, ever looked at its
  db layout?
 
 Could you elaborate?

UDD sprung to mind for me too.  I'd like to know why it
doesn't fit for this use-case.  I'd also be curious in an
armchair-sense to know what's wrong with it's db layout
(I've never looked)


-- 
Jon Dowland


signature.asc
Description: Digital signature


Re: [RFC] Collecting changelog entries in projectb

2010-02-25 Thread Philipp Kern
On 2010-02-24, Joerg Jaspert jo...@debian.org wrote:
 Anyways, the thing is - data should be gathered where it belongs
 to (and is processed anyways). changelogs and other similar data
 actually are something the archive needs to process, so storage is
 easy. Things like UDD should not generate it, but merely be consumers,
 probably linking it to other sources (that have no place in ftpmaster).

I agree with the it should be generated where it's processed part.  We
buildd people would like to get access to live changelog by the way to
generate some mails.  packages.debian.org is not sufficient for that
currently because we need it available when the packages are synced into
the wanna-build database.

Kind regards,
Philipp Kern


-- 
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/slrnhocobs.2pb.tr...@kelgar.0x539.de



Re: [RFC] Collecting changelog entries in projectb

2010-02-25 Thread Guido Günther
On Mon, Feb 01, 2010 at 09:39:45PM +0100, Luca Falavigna wrote:
 Hi,
 
 FTP team and I are currently writing a new feature in dak which will
 collect changelog entries and store them in projectb, to be later used
 for other purposes (e.g. to write point release changelogs, see [1]).
 
 Collecting every changelog entry takes lots of space (the whole past
 adds up to 7GB), so we thought to limit that to policy queues only
 (right now stable-proposed-uploads and oldstable-proposed-uploads),
 unless there is a valid reason to do for every upload in the archive.
 
 Can you imagine a useful thing that is worth having every entry in
 projectb? If so, here's your chance :)
Something like:
  https://honk.sigxcpu.org/cl2vcs/
springs to mind.
Cheers,
 -- Guido


-- 
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/20100225163728.ga18...@bogon.sigxcpu.org



Re: [RFC] Collecting changelog entries in projectb

2010-02-25 Thread Charles Plessy
Le Thu, Feb 25, 2010 at 11:39:40AM +, Philipp Kern a écrit :
 On 2010-02-24, Joerg Jaspert jo...@debian.org wrote:
  Anyways, the thing is - data should be gathered where it belongs
  to (and is processed anyways). changelogs and other similar data
  actually are something the archive needs to process, so storage is
  easy. Things like UDD should not generate it, but merely be consumers,
  probably linking it to other sources (that have no place in ftpmaster).
 
 I agree with the it should be generated where it's processed part.  We
 buildd people would like to get access to live changelog by the way to
 generate some mails.  packages.debian.org is not sufficient for that
 currently because we need it available when the packages are synced into
 the wanna-build database.

Hello everybody,

If the developments on changelog parsing introduce new requirements, in
particular limitations on post-upload corrections, I strongly recommend to
document this in our Policy.

Have a nice day,

-- 
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/20100226004617.gb1...@kunpuu.plessy.org



Re: [RFC] Collecting changelog entries in projectb

2010-02-24 Thread Joerg Jaspert
 FTP team and I are currently writing a new feature in dak which will
 collect changelog entries and store them in projectb, to be later used
 for other purposes (e.g. to write point release changelogs, see [1]).
 Isn't this why we have UDD?

UDD is the wrong approach. And also, ever looked at its db layout?

Anyways, the thing is - data should be gathered where it belongs
to (and is processed anyways). changelogs and other similar data
actually are something the archive needs to process, so storage is
easy. Things like UDD should not generate it, but merely be consumers,
probably linking it to other sources (that have no place in ftpmaster).

-- 
bye, Joerg
exa And mind you, I have always been respectful to every debian
  developer EXCEPT Branden.


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



Re: [RFC] Collecting changelog entries in projectb

2010-02-24 Thread Lucas Nussbaum
On 24/02/10 at 20:19 +0100, Joerg Jaspert wrote:
  FTP team and I are currently writing a new feature in dak which will
  collect changelog entries and store them in projectb, to be later used
  for other purposes (e.g. to write point release changelogs, see [1]).
  Isn't this why we have UDD?
 
 UDD is the wrong approach. And also, ever looked at its db layout?

Could you elaborate?

- Lucas


-- 
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/20100224192537.ga27...@xanadu.blop.info



Re: [RFC] Collecting changelog entries in projectb

2010-02-19 Thread Wouter Verhelst
On Mon, Feb 01, 2010 at 09:39:45PM +0100, Luca Falavigna wrote:
 Hi,
 
 FTP team and I are currently writing a new feature in dak which will
 collect changelog entries and store them in projectb, to be later used
 for other purposes (e.g. to write point release changelogs, see [1]).

Isn't this why we have UDD?
-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100219122031.ge4...@celtic.nixsys.be



Re: [RFC] Collecting changelog entries in projectb

2010-02-02 Thread Tollef Fog Heen
]] Luca Falavigna 

| Can you imagine a useful thing that is worth having every entry in
| projectb? If so, here's your chance :)

Searching for CVEs springs to mind.  (You can have one which only
affects the version in unstable, in which case it would never hit a
policy queue.)

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



[RFC] Collecting changelog entries in projectb

2010-02-01 Thread Luca Falavigna
Hi,

FTP team and I are currently writing a new feature in dak which will
collect changelog entries and store them in projectb, to be later used
for other purposes (e.g. to write point release changelogs, see [1]).

Collecting every changelog entry takes lots of space (the whole past
adds up to 7GB), so we thought to limit that to policy queues only
(right now stable-proposed-uploads and oldstable-proposed-uploads),
unless there is a valid reason to do for every upload in the archive.

Can you imagine a useful thing that is worth having every entry in
projectb? If so, here's your chance :)

[1] http://ftp.debian.org/debian/dists/lenny/ChangeLog

-- 
  .''`.
 :  :' :   Luca Falavigna dktrkr...@debian.org
 `.  `'
   `-


signature.asc
Description: PGP signature