Re: Extended Long Term Support for Wheezy

[Bastian Blank]

On Tue, Feb 27, 2018 at 10:55:25AM +0100, Raphael Hertzog wrote:
> On Mon, 26 Feb 2018, Bastian Blank wrote:
> > On Sun, Feb 25, 2018 at 09:54:27PM +0100, Raphael Hertzog wrote:
> > > Are you suggesting that it should be possible to store our own data
> > > in another git repository and that the tracker should be easily able to
> > > merge the data coming from two distincts repositories ?
> > I've got patches somewhere that do exactly this.
> Nice! Can you try to dig them out? We could then try to merge them
> in the official tracker and write some documentatin on how to do this.

I attached the patch that we used to integrate information about the
super-lts we did for a customer.

/CVE-CUSTOMER/list would get information about ignored CVE and is merged
into the information read from /CVE/list.

/CVE/list was a symlink to the Debian security tracker svn.

/CUSTOMER/list we used for information about security updates and EOL
markers.

Bastian

-- 
Ahead warp factor one, Mr. Sulu.
commit cfc7675b9dac2034cf5fc671653792e8b48dd4db
Author: Bastian Blank 
Date:   Wed Mar 23 10:51:02 2016 +0100

Add support for CUSTOMER bugs and CVE extends

diff --git a/lib/python/bugs.py b/lib/python/bugs.py
index 7258be7..d4d8a0d 100644
--- a/lib/python/bugs.py
+++ b/lib/python/bugs.py
@@ -299,6 +299,28 @@ class Bug(BugBase):
 nts.append(notes[key])
 self.notes = nts
 
+class BugExtend(Bug):
+def writeDB(self, cursor):
+"""Writes the record to an SQLite3 database."""
+
+for (typ, c) in self.comments:
+cursor.execute("""INSERT INTO bugs_notes
+(bug_name, typ, comment) VALUES (?, ?, ?)""",
+   (self.name, typ, c))
+
+for n in self.notes:
+n.writeDB(cursor, self.name)
+
+import apsw
+for x in self.xref:
+try:
+cursor.execute("""INSERT INTO bugs_xref
+(source, target) VALUES (?, ?)""",
+   (self.name, x))
+except apsw.ConstraintError:
+raise ValueError, \
+  "cross reference to %s appears multiple times" % x
+
 class BugFromDB(Bug):
 def __init__(self, cursor, name):
 assert type(name) in types.StringTypes
@@ -440,6 +462,9 @@ class FileBase(debian_support.PackageFile):
 debian_support.PackageFile.__init__(self, name, fileObj)
 self.removed_packages = {}
 
+def isExtend(self, name):
+return False
+
 def isUniqueName(self, name):
 """Returns True if the name is a real, unique name."""
 return True
@@ -723,7 +748,11 @@ class FileBase(debian_support.PackageFile):
 if first_bug:
 break
 record_name = temp_bug_name(first_bug, description)
-yield self.finishBug(Bug(self.file.name, first_lineno, date,
+if self.isExtend(record_name):
+cls = BugExtend
+else:
+cls = Bug
+yield self.finishBug(cls(self.file.name, first_lineno, date,
  record_name, description,
  comments, notes=pkg_notes, xref=xref))
 
@@ -768,6 +797,12 @@ class CVEFile(FileBase):
 bug.mergeNotes()
 return bug
 
+class CVECUSTOMERFile(CVEFile):
+re_cve = 
re.compile(r'^(CVE-\d{4}-(?:\d{4,}|)|TEMP-\d+-\S+)\s+(.*?)\s*$')
+
+def isExtend(self, name):
+return True
+
 class DSAFile(FileBase):
 """A DSA file.
 
@@ -809,6 +844,11 @@ class DSAFile(FileBase):
 bug.mergeNotes()
 return bug
 
+class CUSTOMERFile(DSAFile):
+re_dsa = re.compile(r'^\[(\d\d) ([A-Z][a-z][a-z]) (\d{4})\] '
++ r'(CUSTOMER-\d+(?:-\d+)?)\s+'
++ r'(.*?)\s*$')
+
 class DLAFile(FileBase):
 """A DLA file.
 
diff --git a/lib/python/security_db.py b/lib/python/security_db.py
index e018fff..66032aa 100644
--- a/lib/python/security_db.py
+++ b/lib/python/security_db.py
@@ -908,9 +908,11 @@ class DB:
 
 source_removed_packages = '/packages/removed-packages'
 sources = ((bugs.CVEFile, '/CVE/list'),
+   (bugs.CVECUSTOMERFile, '/CVE-CUSTOMER/list'),
(bugs.DSAFile, '/DSA/list'),
(bugs.DTSAFile, '/DTSA/list'),
(bugs.DLAFile, '/DLA/list'),
+   (bugs.CUSTOMERFile, '/CUSTOMER/list'),
(None, source_removed_packages))
 
 unchanged = True
@@ -963,7 +965,7 @@ class DB:
 old_source = ''
 for source, target in list(cursor.execute(
 """SELECT source, target FROM bugs_xref
-WHERE (source LIKE 'DTSA-%' OR source LIKE 'DSA-%' OR source LIKE 
'DLA-%')
+WHERE (source LIKE 'DTSA-%' OR source LIKE 'DSA-%' OR source LIKE 
'DLA-%' OR source LIKE 'CUSTOMER-%')
 

Re: Extended Long Term Support for Wheezy

[Raphael Hertzog]

Hi,

On Mon, 26 Feb 2018, Peter Palfrader wrote:
> > - for buildd/DSA teams, can we keep wheezy buildds (only amd64/i386 has
> >   been requested so far) for one year more?
> 
> I don't think DSA is thrilled about committing to keep anything other
> than amd64 for anything longer than was already promised.

I assume that you are fine with an amd64 setup building amd64 + i386?

> Even then, we'd want to ensure we are clear on what we commit to.  We'd
> want to run the host on stable only (no "please keep an older kernel
> because reason" or anything like that).  Also, we'd very likely require
> that the complete build chroot be bootstrap-able from the supported
> package set.  If you end up hosting the repo elsewhere, then no building
> on DSA hosts either.

Thanks for the answer. That makes clear requirements that I can explain to
sponsors.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Re: Extended Long Term Support for Wheezy

[Raphael Hertzog]

On Mon, 26 Feb 2018, Bastian Blank wrote:
> On Sun, Feb 25, 2018 at 09:54:27PM +0100, Raphael Hertzog wrote:
> > Are you suggesting that it should be possible to store our own data
> > in another git repository and that the tracker should be easily able to
> > merge the data coming from two distincts repositories ?
> 
> I've got patches somewhere that do exactly this.

Nice! Can you try to dig them out? We could then try to merge them
in the official tracker and write some documentatin on how to do this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Re: Extended Long Term Support for Wheezy

[Peter Palfrader]

On Tue, 20 Feb 2018, Raphael Hertzog wrote:

> - for buildd/DSA teams, can we keep wheezy buildds (only amd64/i386 has
>   been requested so far) for one year more?

I don't think DSA is thrilled about committing to keep anything other
than amd64 for anything longer than was already promised.

Even then, we'd want to ensure we are clear on what we commit to.  We'd
want to run the host on stable only (no "please keep an older kernel
because reason" or anything like that).  Also, we'd very likely require
that the complete build chroot be bootstrap-able from the supported
package set.  If you end up hosting the repo elsewhere, then no building
on DSA hosts either.

(Not a promise, and not coordinated with all of DSA, just my own 20 mFRZ)

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Re: Extended Long Term Support for Wheezy

[Bastian Blank]

On Sun, Feb 25, 2018 at 09:54:27PM +0100, Raphael Hertzog wrote:
> Are you suggesting that it should be possible to store our own data
> in another git repository and that the tracker should be easily able to
> merge the data coming from two distincts repositories ?

I've got patches somewhere that do exactly this.

Bastian

-- 
Totally illogical, there was no chance.
-- Spock, "The Galileo Seven", stardate 2822.3

Re: Extended Long Term Support for Wheezy

[Raphael Hertzog]

On Sun, 25 Feb 2018, Moritz Mühlenhoff wrote:
> The security tracker is fairly flexible and it should take little
> effort to setup a separate instance which is based on the main
> data/our triage efforts while acting on a local Packages file.
> 
> Ideally document this process publicly, so that others can also run
> a local security tracker if they operate a local repository.

We can have another tracker, sure. But then we want to use the data of the
main tracker and we want to push our own data. We could fork the git
repository and merge regularly but it's going to generate lots of
conflicts and will be somewhat annoying to handle.

Are you suggesting that it should be possible to store our own data
in another git repository and that the tracker should be easily able to
merge the data coming from two distincts repositories ?

> > And indeed if we prepare the infrastructure for this by finding a way
> > to host the updates for wheezy for longer than expected, we pave the
> > way for CIP to take over security maintenance of our old releases.
> 
> It's two entirely different things, though. CIP intends to create
> a pool of common packages used by embedded vendors, while the extended
> LTS proposal extends the lifetime of a regular Debian release (for
> the demands of a specific group of users).

Yes, but I believe that those common packages are plain Debian packages.
It's also not clear how many packages are going to be covered but the
initial list looks like very short.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Re: Extended Long Term Support for Wheezy, CIP

[Abhijith PA]

On Thursday 22 February 2018 09:01 PM, Raphael Hertzog wrote:
> Hello,
> 
> On Thu, 22 Feb 2018, Geert Stappers wrote:
>> But what is "CIP"?
>>
>> My websearch did bring up "Clean In Place" and "Christelijk Intromatie 
>> Platform" ...
> 
> It was explained in my first mail.
> 
> Civil Infrastructure Platform
> https://www.cip-project.org/
> 
> Cheers,
> 

There is a talk* about the CIP project in Debconf video archive.

*
https://gemmei.ftp.acc.umu.se/pub/debian-meetings/2017/debconf17/lq/debian-on-civil-infrastructure-systems.vp8.webm

-abhijith

Re: Extended Long Term Support for Wheezy

[Holger Levsen]

On Sun, Feb 25, 2018 at 07:05:52PM +0100, Moritz Mühlenhoff wrote:
> The security tracker is fairly flexible and it should take little
> effort to setup a separate instance which is based on the main
> data/our triage efforts while acting on a local Packages file.
> 
> Ideally document this process publicly, so that others can also run
> a local security tracker if they operate a local repository.

i'm not sure, one the one hand i think this could be a great opportunity
to do this and benefit from this, by doing and documenting this.

(this what Moritz wrote.)

> [...] while the extended
> LTS proposal extends the lifetime of a regular Debian release (for
> the demands of a specific group of users).
 
(true)

while OTOH i think that those people who will run Debian "stale" five
years after it's release, will have largely the similar demands
foremost.

so i can also see how it would be really really *good* to have this on
Debian infrastructure.

(but maybe there already has been too much opposition for this *right now*)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Extended Long Term Support for Wheezy

[Moritz Mühlenhoff]

On Thu, Feb 22, 2018 at 02:57:07PM +0100, Raphael Hertzog wrote:
> But assuming that we keep updates hosted on some debian.org host, do you
> think it's OK to continue to use the security tracker to track
> vulnerabilities in wheezy?

Need to be discussed with the rest of the team, I'm not really
enthuasiastic; if this only supports a subset of the archive this would
clutter the tracker data quite a bit (lots of spurious 
entries e.g.)

The security tracker is fairly flexible and it should take little
effort to setup a separate instance which is based on the main
data/our triage efforts while acting on a local Packages file.

Ideally document this process publicly, so that others can also run
a local security tracker if they operate a local repository.

> And indeed if we prepare the infrastructure for this by finding a way
> to host the updates for wheezy for longer than expected, we pave the
> way for CIP to take over security maintenance of our old releases.

It's two entirely different things, though. CIP intends to create
a pool of common packages used by embedded vendors, while the extended
LTS proposal extends the lifetime of a regular Debian release (for
the demands of a specific group of users).

Cheers,
Moritz

Re: Extended Long Term Support for Wheezy

[Didier 'OdyX' Raboud]

Le jeudi, 22 février 2018, 19.44:06 h CET Roberto C. Sánchez a écrit :
> If we are going to start applying this sort of logic to naming, then
> there are plenty of other places (e.g., where actual vulgarities are
> used in package names, where abreviations and/or acronyms create words
> that are or can be perceived as offensive, etc.).

It's more prominent in suite names than in package descriptions though, as it 
will go in documentation, in apt sources' snippets, etc.

Anyway, not a battle I'll fight; I fully trust the proponents to have heard 
that argument and make a sane suite name choice :-)

Cheers,
OdyX

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

Re: Extended Long Term Support for Wheezy

[Roberto C . Sánchez]

On Thu, Feb 22, 2018 at 07:31:23PM +0100, Didier 'OdyX' Raboud wrote:
> Le mardi, 20 février 2018, 16.07:03 h CET Raphael Hertzog a écrit :
> > ("super long-term maintenance", SLTS in their jargon)
> 
> A small point, but I haven't seen anyone mention it yet: I would not use the 
> 'slts' acronym, basically anywhere, as it is very close to the 'sluts' smear 
> word.
> 
You haven't seen anyone mention it because it is nonsense. The acronym
is also close to 'slats', 'slits', and 'slots', not to mention 'salts',
'stilts', and who knows how many other words in the English language.

If we are going to start applying this sort of logic to naming, then
there are plenty of other places (e.g., where actual vulgarities are
used in package names, where abreviations and/or acronyms create words
that are or can be perceived as offensive, etc.).

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Extended Long Term Support for Wheezy

[Didier 'OdyX' Raboud]

Le mardi, 20 février 2018, 16.07:03 h CET Raphael Hertzog a écrit :
> ("super long-term maintenance", SLTS in their jargon)

A small point, but I haven't seen anyone mention it yet: I would not use the 
'slts' acronym, basically anywhere, as it is very close to the 'sluts' smear 
word.

Cheers,
OdyX

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

Re: Extended Long Term Support for Wheezy

[Bastian Blank]

Hi Raphael

On Thu, Feb 22, 2018 at 02:57:07PM +0100, Raphael Hertzog wrote:
> > I would however suggest that it should not be part of the normal mirror
> > area, since:
> Ack on all this. That's why I suggested to keep only the part on
> security.debian.org and drop the part on the main mirror.

This would mean all the still supported packages will need to be
imported into security.debian.org.  I don't think this is a good idea.

> But we can also consider setting up slts.debian.org (Super Long Term
> Maintenance) and move wheezy entirely over there.

I would first think about a new suite on the main archive, wheezy-slts,
where only the supported packages remain.

> Could this be a new DAK install managed by ftp-masters that would
> be continued to be signed with the official wheezy key?

The Wheezy key expires "pretty soon"[tm].  They would need to migrate to
a new key anyway.

| pub   rsa4096 2012-04-27 [SC] [expires: 2020-04-25]
|   A1BD 8E9D 78F7 FE5C 3E65  D8AF 8B48 AD62 4692 5553
| uid   [ unknown] Debian Archive Automatic Signing Key (7.0/wheezy) 


> Otherwise
> it will be harder for users to transition if they have to install
> a new key. Or is there a way to let another team manage the repository and
> still get official signatures of the repositories?

Unlikely.

Bastian

-- 
Military secrets are the most fleeting of all.
-- Spock, "The Enterprise Incident", stardate 5027.4

Re: Extended Long Term Support for Wheezy

[Ben Hutchings]

On Thu, 2018-02-22 at 16:51 +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Thu, 22 Feb 2018, Lars Wirzenius wrote:
> > I don't have an opinion on whether this should be done on Debian
> > servers or not, but I have a comment on providing security support for
> > more than a decade. How do you plan to deal with the kernel?
> 
> FTR, I'm not involved in CIP and thus I can't speak for them but since
> I was in contact with them, I have looked at their wiki and you will
> find their plans related to the kernel here:
> https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance
> 
> And as you see, we have Debian people involved since Ben Hutching is
> currently maintaining their "Super Long Term Support" kernel which is
> based on Linux 4.4.
> 
> That said I'm not sure if their SLTS kernel will ever be suitable for
> use in Debian. Maybe Ben can comment on this.

I think the criteria for patch inclusion in CIP and Debian kernels are
very close.  If we align on a base kernel version, CIP may be able to
use the Debian kernel package as an upstream and send its additions
(for new hardware support) to Debian for inclusion.  (I'm not sure how
CIP would handle this technically, since Debian uses a quilt series in
git whereas CIP uses a normal git branch.  But there are ways of
converting from one to the other.)

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. ... I realized that a large part of my life from then on was
going to be spent in finding mistakes in my own programs. - Maurice
Wilkes, 1949



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

Re: Extended Long Term Support for Wheezy

[Raphael Hertzog]

Hi,

On Thu, 22 Feb 2018, Lars Wirzenius wrote:
> I don't have an opinion on whether this should be done on Debian
> servers or not, but I have a comment on providing security support for
> more than a decade. How do you plan to deal with the kernel?

FTR, I'm not involved in CIP and thus I can't speak for them but since
I was in contact with them, I have looked at their wiki and you will
find their plans related to the kernel here:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance

And as you see, we have Debian people involved since Ben Hutching is
currently maintaining their "Super Long Term Support" kernel which is
based on Linux 4.4.

That said I'm not sure if their SLTS kernel will ever be suitable for
use in Debian. Maybe Ben can comment on this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Re: Extended Long Term Support for Wheezy

[Ben Hutchings]

On Thu, 2018-02-22 at 16:31 +0200, Lars Wirzenius wrote:
> I don't have an opinion on whether this should be done on Debian
> servers or not, but I have a comment on providing security support for
> more than a decade. How do you plan to deal with the kernel? Do you
> expect to backport security fixes to the wheezy kernel, or upgrade
> the kernel to newer versions from time to time?

I don't know about the proposed wheezy SLTS as I haven't committed to
participate in it, but I would expect the former.

> A newer kernel may be
> necessary for hardware support as well. What's your plan on that? In
> addition to the kernel, the rest of the plumbing layer may need
> upgrades to handle hardware support, security, changes elsewhere.
[...]

The plan in CIP is to backport hardware support to the newest SLTS
branch only.  Old hardware can continue running kernels built from an
old branch but new hardware will only be supported on the new branch.

The cadence of SLTS kernel branches is not yet determined, but if 
CIP successfully aligns with Debian then they will presumably be
started at 2 or 4 year intervals.  This is likely to mean that no new
hardware support is added beyond the LTS period.

Some more details here:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. ... I realized that a large part of my life from then on was
going to be spent in finding mistakes in my own programs. - Maurice
Wilkes, 1949


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

Re: Extended Long Term Support for Wheezy, CIP

[Raphael Hertzog]

Hello,

On Thu, 22 Feb 2018, Geert Stappers wrote:
> But what is "CIP"?
> 
> My websearch did bring up "Clean In Place" and "Christelijk Intromatie 
> Platform" ...

It was explained in my first mail.

Civil Infrastructure Platform
https://www.cip-project.org/

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Re: Extended Long Term Support for Wheezy, CIP

[The Wanderer]

On 2018-02-22 at 09:45, Geert Stappers wrote:

> On Thu, Feb 22, 2018 at 02:57:07PM +0100, Raphael Hertzog wrote:

>> On Thu, 22 Feb 2018, Philip Hands wrote:
>> 
>>> I'm in favour of making it possible for our users to build
>>> structures that enable longer support periods if that's what they
>>> require. There would seem to be a need for an OS that would have
>>> support measured in decades rather than years, and we should not
>>> get in the way of Debian being that OS.
>> 
>> Indeed. And it's the reason why I mentionned CIP in my initial
>> mail. They are not interested in longer support for wheezy (too
>> early for them) but they are interested in working with us and
>> helping us to make this possible as part of Debian.  One of the
>> persons I am in contact with mentioned that CIP members could (at
>> some point) contribute security updates within Debian.
>> 
>> Looking a bit further, I see a way forward where we have the
>> security team (first 3 years), the LTS team (next 2 years), CIP
>> members (next 10 years) taking over the charge of security updates
>> for a given release.
>> 
>> And indeed if we prepare the infrastructure for this by finding a
>> way to host the updates for wheezy for longer than expected, we
>> pave the way for CIP to take over security maintenance of our old
>> releases.

> But what is "CIP"?
> 
> 
> My websearch did bring up "Clean In Place" and "Christelijk
> Intromatie Platform" ...

Referring back to Raphael's original mail, it would appear to stand for
"Civil Infrastructure Project".

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: Extended Long Term Support for Wheezy, CIP

[Geert Stappers]

On Thu, Feb 22, 2018 at 02:57:07PM +0100, Raphael Hertzog wrote:
> Hello,
> 
> On Tue, 20 Feb 2018, Moritz Mühlenhoff wrote:
> > LTS has a clearly defined scope, while this is essentially contracting
> > work to extend the life time of some packages for some customers.
> > 
> > I don't see a compelling reason for it to run on Debian infrastructure.
> 
> This was also my first feeling but if you include the CIP into
> the picture, you can conceive this as a first step into a new direction.
> Let me explain at the end.
> 
> But assuming that we keep updates hosted on some debian.org host, do you
> think it's OK to continue to use the security tracker to track
> vulnerabilities in wheezy?
> 
> On Tue, 20 Feb 2018, Joerg Jaspert wrote:
> > If this would be "just" extending the current LTS ways for more time,
> > then it would be OKish to stay on donated, voluntarily managed,
> > infrastructure. After all it helps all users of wheezy with updates,
> > nominally over all of wheezy.
> > 
> > But the proposal is effectively just for a benefit of a few paying
> > customers, with a very selected set of packages and architectures, all
> > the rest lost out. Thats not ok to ask volunteers to support, nor
> > is it ok to use projects infrastructure for. The companies that want it,
> > should run it.
> 
> Just to clarify, the set of packages/architectures supported is
> effectively selected by the sponsors, but the resulting work is
> made available to all.
> 
> On Thu, 22 Feb 2018, Philip Hands wrote:
> > I'm in favour of making it possible for our users to build structures
> > that enable longer support periods if that's what they require. There
> > would seem to be a need for an OS that would have support measured in
> > decades rather than years, and we should not get in the way of Debian
> > being that OS.
> 
> Indeed. And it's the reason why I mentionned CIP in my initial mail. They
> are not interested in longer support for wheezy (too early for them) but
> they are interested in working with us and helping us to make this
> possible as part of Debian.  One of the persons I am in contact with
> mentioned that CIP members could (at some point) contribute security
> updates within Debian.
> 
> Looking a bit further, I see a way forward where we have the security
> team (first 3 years), the LTS team (next 2 years), CIP members (next 10
> years) taking over the charge of security updates for a given release.
> 
> And indeed if we prepare the infrastructure for this by finding a way
> to host the updates for wheezy for longer than expected, we pave the
> way for CIP to take over security maintenance of our old releases.
> 
> > I would however suggest that it should not be part of the normal mirror
> > area, since:
> 
> Ack on all this. That's why I suggested to keep only the part on
> security.debian.org and drop the part on the main mirror.
> But we can also consider setting up slts.debian.org (Super Long Term
> Maintenance) and move wheezy entirely over there.
> 
> Could this be a new DAK install managed by ftp-masters that would
> be continued to be signed with the official wheezy key? Otherwise
> it will be harder for users to transition if they have to install
> a new key. Or is there a way to let another team manage the repository and
> still get official signatures of the repositories?
> 
> Cheers,
> -- 
> Raphaël Hertzog ??? Debian Developer
> 
> Support Debian LTS: https://www.freexian.com/services/debian-lts.html
> Learn to master Debian: https://debian-handbook.info/get/
> 

But what is "CIP"?


My websearch did bring up "Clean In Place" and "Christelijk Intromatie 
Platform" ...


Groeten
Geert Stappers
-- 
Leven en laten leven

Re: Extended Long Term Support for Wheezy

[Lars Wirzenius]

I don't have an opinion on whether this should be done on Debian
servers or not, but I have a comment on providing security support for
more than a decade. How do you plan to deal with the kernel? Do you
expect to backport security fixes to the wheezy kernel, or upgrade the
kernel to newer versions from time to time? A newer kernel may be
necessary for hardware support as well. What's your plan on that? In
addition to the kernel, the rest of the plumbing layer may need
upgrades to handle hardware support, security, changes elsewhere.

I wouldn't want to put a device with Linux kernel from the 2.2 era
(2013) on the Internet anymore. I wouldn't want to put a device with
4.15.4 in 2033.

Personally, I don't find backporting kernel and plumbing changes for
over a decade to be a viable approach. I find planning to upgrade
software on the devices is the way to go. On the other hand, I'm no
longer working on things expected to last 25 years, though I did do
that in a previous job.

While I'm sceptical, Ḯ'm not saying that it can't be done, so I'm not
objecting. Instead, I'm asking, what your plans for this are?


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

Re: Extended Long Term Support for Wheezy

[Michael Stone]

On Tue, Feb 20, 2018 at 11:48:43PM +0100, Joerg Jaspert wrote:

If this would be "just" extending the current LTS ways for more time,
then it would be OKish to stay on donated, voluntarily managed,
infrastructure. After all it helps all users of wheezy with updates,
nominally over all of wheezy.

But the proposal is effectively just for a benefit of a few paying
customers, with a very selected set of packages and architectures, all
the rest lost out. 


To play devil's advocate, isn't this just a more explicit summary of how 
security support works in debian generally? When a package gets to be to 
hard to maintain, it just stops getting security updates. When an 
architecture gets to be too much cost for the benefit of updating, it 
doesn't get LTS. I don't see how the fact that some people are paying 
directly changes anything; there are already debian developers who get 
paid for doing debian work, and it's not as though the people who are 
purely volunteers can be made to work on anything in particular any more 
than the people who are getting paychecks. As long as the packages which 
come out of this are available for everyone I think it's a net win for 
the community and a reasonable use of debian resources. If someone wants 
more packages supported they could always pay for it or do the work, 
right?


Mike Stone

Re: Extended Long Term Support for Wheezy

[Raphael Hertzog]

Hello,

On Tue, 20 Feb 2018, Moritz Mühlenhoff wrote:
> LTS has a clearly defined scope, while this is essentially contracting
> work to extend the life time of some packages for some customers.
> 
> I don't see a compelling reason for it to run on Debian infrastructure.

This was also my first feeling but if you include the CIP into
the picture, you can conceive this as a first step into a new direction.
Let me explain at the end.

But assuming that we keep updates hosted on some debian.org host, do you
think it's OK to continue to use the security tracker to track
vulnerabilities in wheezy?

On Tue, 20 Feb 2018, Joerg Jaspert wrote:
> If this would be "just" extending the current LTS ways for more time,
> then it would be OKish to stay on donated, voluntarily managed,
> infrastructure. After all it helps all users of wheezy with updates,
> nominally over all of wheezy.
> 
> But the proposal is effectively just for a benefit of a few paying
> customers, with a very selected set of packages and architectures, all
> the rest lost out. Thats not ok to ask volunteers to support, nor
> is it ok to use projects infrastructure for. The companies that want it,
> should run it.

Just to clarify, the set of packages/architectures supported is
effectively selected by the sponsors, but the resulting work is
made available to all.

On Thu, 22 Feb 2018, Philip Hands wrote:
> I'm in favour of making it possible for our users to build structures
> that enable longer support periods if that's what they require. There
> would seem to be a need for an OS that would have support measured in
> decades rather than years, and we should not get in the way of Debian
> being that OS.

Indeed. And it's the reason why I mentionned CIP in my initial mail. They
are not interested in longer support for wheezy (too early for them) but
they are interested in working with us and helping us to make this
possible as part of Debian.  One of the persons I am in contact with
mentioned that CIP members could (at some point) contribute security
updates within Debian.

Looking a bit further, I see a way forward where we have the security
team (first 3 years), the LTS team (next 2 years), CIP members (next 10
years) taking over the charge of security updates for a given release.

And indeed if we prepare the infrastructure for this by finding a way
to host the updates for wheezy for longer than expected, we pave the
way for CIP to take over security maintenance of our old releases.

> I would however suggest that it should not be part of the normal mirror
> area, since:

Ack on all this. That's why I suggested to keep only the part on
security.debian.org and drop the part on the main mirror.
But we can also consider setting up slts.debian.org (Super Long Term
Maintenance) and move wheezy entirely over there.

Could this be a new DAK install managed by ftp-masters that would
be continued to be signed with the official wheezy key? Otherwise
it will be harder for users to transition if they have to install
a new key. Or is there a way to let another team manage the repository and
still get official signatures of the repositories?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Re: Extended Long Term Support for Wheezy

[Mathias Behrle]

* Philip Hands: " Re: Extended Long Term Support for Wheezy" (Thu, 22 Feb 2018
  08:46:16 +0100):

> On Wed, 21 Feb 2018, m...@linux.it (Marco d'Itri) wrote:
> > On Feb 21, Antonio Terceiro <terce...@debian.org> wrote:
> >  
>  [...]  
> > Indeed. If the scope of the project is reasonable and clearly defined 
> > then I would definitely be in favour of distributing the results in the 
> > Debian archive.  
> 
> I'm in favour of making it possible for our users to build structures
> that enable longer support periods if that's what they require. There
> would seem to be a need for an OS that would have support measured in
> decades rather than years, and we should not get in the way of Debian
> being that OS.
> 
> If doing this stepping-stone to longer support allows sponsors to get
> used to funding such very-long-term support, then I think we should give
> it a chance to develop as part of Debian.
> 
> Once the funding dries up for Wheezy, we can always decide it didn't
> really work out and not do it for future releases.
> 
> I would however suggest that it should not be part of the normal mirror
> area, since:
> 
>   There is going to be a step-change in the level of support, with many
>   more packages dropping out of support.  Users should have to notice
>   this and update their sources.lists as they see fit.

While I agree completely with your mail, Phil, I would add even more concerns
about the general usability of a distribution tailored for just a few target
users in terms of security support. I think other users (than the sponsors) of
this distribution should be warned very clearly about the specific and
restricted security support.

Since we (most probably) don't know at this stage which subset of all packages
will be supported it is really difficult to assess the benefit of this
distribution and if it can be recommended for general usage. Therefore I
would consider it finally better to not use the Debian infrastructure at least
for the distribution of these packages.

>   We don't want to inflict ever increasing demands for space on the
>   mirror network by keeping ever older, mostly obsolete, distros around.
>   Especially since it might be that very few people end up using them.
> 
>   I'd have thought that the sponsors should be willing to set up mirrors
>   for these repos. if there is a need for mirrors (since they're quite
>   likely to do that anyway for internal use, and so just need to provide
>   public access to those).

+1
 
> Cheers, Phil.

Cheers,
Mathias


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Re: Extended Long Term Support for Wheezy

[Philip Hands]

On Wed, 21 Feb 2018, m...@linux.it (Marco d'Itri) wrote:
> On Feb 21, Antonio Terceiro  wrote:
>
>> Maybe the proposal needs to be clarified, but my understanding was that
>> some companies are willing to fund a longer LTS for a restricted set of
>> packages and architectures¹, but that the product of that would continue
>> to be available for anyone.
> Indeed. If the scope of the project is reasonable and clearly defined 
> then I would definitely be in favour of distributing the results in the 
> Debian archive.

I'm in favour of making it possible for our users to build structures
that enable longer support periods if that's what they require. There
would seem to be a need for an OS that would have support measured in
decades rather than years, and we should not get in the way of Debian
being that OS.

If doing this stepping-stone to longer support allows sponsors to get
used to funding such very-long-term support, then I think we should give
it a chance to develop as part of Debian.

Once the funding dries up for Wheezy, we can always decide it didn't
really work out and not do it for future releases.

I would however suggest that it should not be part of the normal mirror
area, since:

  There is going to be a step-change in the level of support, with many
  more packages dropping out of support.  Users should have to notice
  this and update their sources.lists as they see fit.

  We don't want to inflict ever increasing demands for space on the
  mirror network by keeping ever older, mostly obsolete, distros around.
  Especially since it might be that very few people end up using them.

  I'd have thought that the sponsors should be willing to set up mirrors
  for these repos. if there is a need for mirrors (since they're quite
  likely to do that anyway for internal use, and so just need to provide
  public access to those).

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Extended Long Term Support for Wheezy

[Marco d'Itri]

On Feb 21, Antonio Terceiro  wrote:

> Maybe the proposal needs to be clarified, but my understanding was that
> some companies are willing to fund a longer LTS for a restricted set of
> packages and architectures¹, but that the product of that would continue
> to be available for anyone.
Indeed. If the scope of the project is reasonable and clearly defined 
then I would definitely be in favour of distributing the results in the 
Debian archive.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Extended Long Term Support for Wheezy

[Antonio Terceiro]

On Tue, Feb 20, 2018 at 11:48:43PM +0100, Joerg Jaspert wrote:
> On 14954 March 1977, Raphael Hertzog wrote:
> 
> > - for ftpmasters, can we keep wheezy/updates on security.debian.org for
> >   one year more?  (it might be possible to archive wheezy and drop it from
> >   the main mirror, that would be a clear sign to everybody that something
> >   important changed, and we could reconfigure the buildd to use another
> >   repository)
> 
> No.
> 
> > - are there other problems related to this extended LTS that need to be
> >   discussed?
> 
> If this would be "just" extending the current LTS ways for more time,
> then it would be OKish to stay on donated, voluntarily managed,
> infrastructure. After all it helps all users of wheezy with updates,
> nominally over all of wheezy.
> 
> But the proposal is effectively just for a benefit of a few paying
> customers, with a very selected set of packages and architectures, all
> the rest lost out. Thats not ok to ask volunteers to support, nor
> is it ok to use projects infrastructure for. The companies that want it,
> should run it.

Maybe the proposal needs to be clarified, but my understanding was that
some companies are willing to fund a longer LTS for a restricted set of
packages and architectures¹, but that the product of that would continue
to be available for anyone.

I assume that Raphael knows that it wouldn't even make sense to ask if
that could be done in Debian infrastructure if it wasn't available to
all users.

¹ LTS is _already_ for a restricted set of packages and architectures,
  so this is just extra constraining to allow for longer support


signature.asc
Description: PGP signature

Re: Extended Long Term Support for Wheezy

[Joerg Jaspert]

On 14954 March 1977, Raphael Hertzog wrote:

> - for ftpmasters, can we keep wheezy/updates on security.debian.org for
>   one year more?  (it might be possible to archive wheezy and drop it from
>   the main mirror, that would be a clear sign to everybody that something
>   important changed, and we could reconfigure the buildd to use another
>   repository)

No.

> - are there other problems related to this extended LTS that need to be
>   discussed?

If this would be "just" extending the current LTS ways for more time,
then it would be OKish to stay on donated, voluntarily managed,
infrastructure. After all it helps all users of wheezy with updates,
nominally over all of wheezy.

But the proposal is effectively just for a benefit of a few paying
customers, with a very selected set of packages and architectures, all
the rest lost out. Thats not ok to ask volunteers to support, nor
is it ok to use projects infrastructure for. The companies that want it,
should run it.

-- 
bye, Joerg

Re: Extended Long Term Support for Wheezy

[Julien Cristau]

On Tue, Feb 20, 2018 at 22:42:46 +0100, Moritz Mühlenhoff wrote:

> Raphael Hertzog wrote:
> > some of the LTS sponsors are looking to extend the support period of
> > Debian 7 Wheezy (from a few months up to a full year).
> >
> > Our question is whether this can be done on debian.org infrastructure.
> 
> LTS has a clearly defined scope, while this is essentially contracting
> work to extend the life time of some packages for some customers.
> 
> I don't see a compelling reason for it to run on Debian infrastructure.
> 
+1, FWIW.

Cheers,
Julien

Re: Extended Long Term Support for Wheezy

[Moritz Mühlenhoff]

Raphael Hertzog wrote:
> some of the LTS sponsors are looking to extend the support period of
> Debian 7 Wheezy (from a few months up to a full year).
>
> Our question is whether this can be done on debian.org infrastructure.

LTS has a clearly defined scope, while this is essentially contracting
work to extend the life time of some packages for some customers.

I don't see a compelling reason for it to run on Debian infrastructure.

Cheers,
 Moritz

Re: Extended Long Term Support for Wheezy

[Jens Korte]

Hi

How would you organize and call it in the wiki name space, ELTS,
extended LTS, LTS? Would you use the normal LTS name space and make no
difference? LTS is on the one side the name for the support after
oldstable and on the other side the general name for LTS and ELTS.

Greets

Jens Korte

Am Tue, 20 Feb 2018 16:07:03 +0100
schrieb Raphael Hertzog :

> [ Bcc to ftpmasters, wanna-build team, DSA team, LTS team, security
> team to catch their attention ]
> 
> Hello,
> 
> some of the LTS sponsors are looking to extend the support period of
> Debian 7 Wheezy (from a few months up to a full year). Some of the LTS
> sponsors (notably Plat'Home, Toshiba) are also members of the Civil
> Infrastructure Project which wants to build an "open source base layer
> (OSBL) for embedded systems" that would be supported for 15 years or
> more ("super long-term maintenance", SLTS in their jargon) and it
> looks like that Debian is their reference distribution to build this:
> https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip-core
> 
> I queried the current set of paid contributors and we have enough
> volunteers (6) to actually make this "extended LTS" happen for one
> supplementary year, at least from the "providing security updates"
> side.
> 
> The problem is that this extension would not work like the regular
> LTS period. Due to the decreased interest for this extension, we would
> only support the set of packages requested by the sponsors and the
> sponsors will have to pay their (varying) share of the workload
> generated by the packages they use.
> 
> Our question is whether this can be done on debian.org infrastructure.
> All sponsors and CIP members would largely prefer if we could continue
> to provide security updates through the usual debian.org channels.
> It's also the best way to let everybody benefit from the work done
> within this project. But it might be a bit misleading given that the
> rules would have again changed.
> 
> So here are a few questions to the various teams:
> 
> - for ftpmasters, can we keep wheezy/updates on security.debian.org
> for one year more?  (it might be possible to archive wheezy and drop
> it from the main mirror, that would be a clear sign to everybody that
> something important changed, and we could reconfigure the buildd to
> use another repository)
> 
> - for security team, can we continue to use the security tracker for
>   wheezy for one year more? (or even longer in the context of CIP)
> 
> - for buildd/DSA teams, can we keep wheezy buildds (only amd64/i386
> has been requested so far) for one year more?
> 
> - are there other problems related to this extended LTS that need to
> be discussed?
> 
> I'm happy to answer any question that you might have.
> 
> Cheers,