staging security updates

[Antoine Beaupré]

On 2016-04-28 02:54:36, Brian May wrote:
> - Created private signed repository for staging my proposed updates for
>   testing. https://people.debian.org/~bam/debian/

So I've been thinking about this as well, and this seems to be a
resource we all need and should figure out a way to implement in a
broader scope.

Right now, i also have my own ad-hoc repo on people.debian.org, but I
haven't made the jump of deploying reprepro out there, and before I do
that, I figured it would be nice to discuss with others how best to
implement this collectively.

For me, the requirement is to have an archive where we can publish
non-embargoed security upgrades for broader testing before it migrates
in the regular security suite. Optionally, it could also (reproducibly?)
build the packages for all supported architectures.

I've looked at Debomatic just to get things out the door, but I'm still
waiting for accesses there. Because it's not an official project and
it doesn't bridge with our existing authentication mechanisms, that
doesn't seem to be an option that works well just yet. Plus the suites
are setup weirdly[1] and there and there's no "wheezy" suite.

 [1] 
http://debomatic-amd64.debian.net/debomatic/jessie-backports/dists/jessie-backports/

Could we have a proposed-updates suite for security the same way we have
for stable point releases? I know we generally want to push security
updates out as quickly as possible, but some issues are very public
already and we sometimes lag enough that it doesn't matter that we take
a few more days giving the chance people to test things first. This is
especially relevant with LTS where we generally *are* lagging behind
updates, basically by design.

I know there's a sensitive issue of using Debian infrastructure for
consulting at play here. Maybe we can flip that around and actually
*leverage* LTS sponsors to make something work for Debian as a whole. :)

Is that crazy? Not a new idea? Flamebait? Thanks for any feedback. :)

A.

-- 
In a world where Henry Kissinger wins the Nobel Peace Prize,
there is no need for satire.
- Tom Lehrer

Re: Please remove non-lts architectures from wheezy-security

[Raphael Hertzog]

Hello Ansgar,

thanks for your work!

On Thu, 28 Apr 2016, Ansgar Burchardt wrote:
> I'm not quite sure if uploading new packages will trigger a mirror
> push.  I think that only happens when uploads to policy queues are
> processed and might need to be adapted.

I guess that if you are not able to do it quickly, you will be able to
put it in some cron task in the mean time?

> I also still need to look at the patches to have the dak installation on
> security-master also send mail to the person that signed the upload.

Can you also make sure that Accepted mails are sent to
debian-lts-chan...@lists.debian.org and to the package tracker
(dispatch _AT_ tracker.debian.org)?

> > It would be nice if in the future we can have the suites from the
> > security archive called -security by dak.
> 
> This I hope to change for stretch.  Having */updates and *-updates is
> too confusing...

Yeah \o/

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Please remove non-lts architectures from wheezy-security

[Ansgar Burchardt]

Hi,

Aurelien Jarno writes:
> On 2016-04-26 23:52, Ansgar Burchardt wrote:
>> please remove the non-lts architectures for wheezy-security from
>> wanna-build and the buildds.  Only amd64, armel, armhf and i386 are
>> still supported.
>>
>> It would also be nice if build logs for wheezy-security would be visible
>> on buildd.d.o for future uploads. (As far as I know, LTS doesn't handle
>> embargoed issues so public logs should be fine.)
>
> That should have been done by now. A bit complicated because
> wheezy-security is a virtual suite, which now has different
> architectures than the real suite wheezy.

Thanks.  I removed the non-lts architectures from the wheezy suite on
security-master and disabled the policy queues.  So uploads should now
be accepted.

I'm not quite sure if uploading new packages will trigger a mirror
push.  I think that only happens when uploads to policy queues are
processed and might need to be adapted.

I also still need to look at the patches to have the dak installation on
security-master also send mail to the person that signed the upload.

> It would be nice if in the future we can have the suites from the
> security archive called -security by dak.

This I hope to change for stretch.  Having */updates and *-updates is
too confusing...

Ansgar

April Report

[Brian May]

In April 2016, my second month as a debian-lts contributor, I was
allocated 10 hours and I used all the 10 hours.

In this time I did the following:

- Released security update of imagemagick to wheezy-security.
- Lots of work on libav and dependancies of libav.
- Created private signed repository for staging my proposed updates for
  testing. https://people.debian.org/~bam/debian/

There is much work remaining fixing the dependancies of libav, which I
plan to continue on - as much as feasible anyway - next month. ffmpeg
might be a stumbling point.
-- 
Brian May 
https://linuxpenguins.xyz/brian/


signature.asc
Description: PGP signature

Re: tracking security issues without CVEs

[Paul Wise]

On Mon, Mar 28, 2016 at 10:34 PM, Andrew Deck wrote:

> On a related note, does anyone know what happened to OSF and the OSVDB?
> There still seem to be blog updates, but I remember OSVDB having a web
> UI, and the OSF website seems to be down.

They have officially closed the OSVDB site:

https://blog.osvdb.org/2016/04/05/osvdb-fin/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise