- To: Pau Garcia i Quiles <email@example.com>
- Cc: Michael Gilbert <firstname.lastname@example.org>, email@example.com
- From: Ian Jackson <firstname.lastname@example.org>
- Date: Mon, 7 Nov 2011 18:12:42 +0000
- Message-id: <[🔎] email@example.com>
- In-reply-to: <CAKcBokuijJu-o_W1vTMX0AYrUqSZ9cheUcOSLF3TSb3fjWxjWQ@mail.gmail.com>
- References: <20111023151317.GA26161@rivendell.home.ouaza.com> <firstname.lastname@example.org> <email@example.com> <4EA889CB.firstname.lastname@example.org> <CANTw=MOZQNeauKuGZDvf1EOWPCmt9DGLarqWrkWm3_3W-WKw9A@mail.gmail.com> <email@example.com> <CAKcBokuijJu-o_W1vTMX0AYrUqSZ9cheUcOSLF3TSb3fjWxjWQ@mail.gmail.com>
> On Thu, Oct 27, 2011 at 1:28 AM, Ian Jackson
> <firstname.lastname@example.org> wrote:
> > The difficulty is that if we end up with ten different versions of
> > vulnerability we need to somehow backport the patch to each of those
> > ten versions.
> > And here "we" means the security team, not the people who uploaded the
> > ten versions in the first place.
> > So this is rather unpalatable.
> What's the alternative?
> It seems that we only have two choices:
> - Each package works with the upstream-bundled version of the
We could do this:
* No JS libraries should be bundled into binary packages; instead,
each package should Depend on an appropriate separate JS library
* JS library packages should be versioned in the name, like C runtime
library packages are, so that multiple versions are coinstallable.
* If the number of different versions of a single JS library becomes
"too large", ftp-master and/or the security team will call a halt
and the uploads and/or testing migrations of some of them will be