Announcement of long term support for Debian oldstable

[SECURITY] [DSA 2907-1] Announcement of long term support for Debian oldstable
(5 év a kiadás megjelenésétől számítva)

A következő levél témája:
„Ez egy előzetes értesítés, hogy a rendszeres biztonsági támogatás a Debian GNU / Linux 6.0 (kódnevén "squeeze") 2014. május 31-én megszűnne,
# Egy újabb kiadás megjelenése után egy évig tart a Debian biztonsági frissítési támogatása az oldstable verzióra.
azonban mi örömmel jelentjük be, hogy az oldstable disztribúció, a Debian Squeeze részére a biztonsági támogatást meg fogjuk hosszabbítani, 2016. februárig, vagyis öt évvel a - most oldstable - kiadás megjelenésétől számítva. Ez a törekvés (LTS - Long Term Support) vezérli a különböző érdekelt feleket / vállalatokat, amelyeknek így az igényeit a hosszabb biztonsági támogatásra jobban ki tudjuk szolgálni ...”

#####
Kapcsolódó hivatkozások:
- DebianSqueeze
https://wiki.debian.org/DebianSqueeze
- DebianReleases
https://wiki.debian.org/DebianReleases
- Debian “squeeze” Release Information
http://www.debian.org/releases/squeeze/
- DebianOldStable
https://wiki.debian.org/DebianOldStable
#####

A levél

- -------------------------------------------------------------------------
Debian Security Advisory DSA-2907-1                   [email protected]
http://www.debian.org/security/                        Moritz Muehlenhoff
April 16, 2014                         http://www.debian.org/security/faq
- -------------------------------------------------------------------------

This is an advance notice that regular security support for Debian
GNU/Linux 6.0  (code name "squeeze") will be terminated on the 31st of
May.

However, we're happy to announce that security support for squeeze is
going to be extended until February 2016, i.e. five years after the
initial release. This effort is driven by various interested parties /
companies which require longer security support. See the "LTS" section
of https://lists.debian.org/debian-devel-announce/2014/03/msg00004.html
for the initial announcement.

The details are currently being sorted out and a more detailed
announcement will be made soon.

Brief advance FAQ (but you should really wait for the more detailed
announcement):

Q: What's the difference between regular security support and the LTS
   support?
A: squeeze-lts is only going to support i386 and amd64. If you're
   running a different architecture you need to upgrade to Debian 7
   (wheezy). Also there are going to be a few packages which will not
   be supported in squeeze-lts (e.g. a few web-based applications
   which cannot be supported for five years). There will be a tool to
   detect such unsupported packages.

Q: Does this mean that Debian 7 (wheezy) and/or Debian 8 (jessie) will
   have five years security support as well?
A: Likely, we'll see how squeeze-lts turns out. If there's sufficient
   support it will be continued for later releases as well. Also, see
   below.

Q: Is additional help needed?
A: Absolutely. squeeze-lts is not handled by the Debian security team,
   but by a separate group of volunteers and companies interested in
   making it a success (with some overlap in people involved). So, if
   you're a company using Debian and seeing a benefit in security
   support for five years, get in touch with [email protected]
   and we'll see how you can help (if you e.g. don't have the manpower /
   know how but are willing to contribute, we can point you to a list
   of Debian consultants)

Mailing list: [email protected]


A levélben hivatkozott oldal
https://lists.debian.org/debian-devel-announce/2014/03/msg00004.html
tartalma:

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]
Bits from the Security Team

    To: [email protected]
    Subject: Bits from the Security Team
    From: Moritz Muehlenhoff <[email protected]>
    Date: Wed, 5 Mar 2014 20:03:01 +0100
    Message-id: <[email protected]>
    Mail-followup-to: [email protected]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The Debian Security Team met on the first weekend of February at the
Linux Hotel in Essen (along with an FTP master for archive/dak-related
issues). Here's a summary of what was discussed and done. It also
lists various useful tasks for which volunteers are welcome in order
to speed things up.

Attendees: carnil, corsac, fw, jmm, luciano, geissert, ganneff

Debian Security Tracker
- -----------------------

* In some cases source packages get renamed, e.g. the source package
  for the Linux kernel was called "linux-2.6" in oldstable and is
  "linux" in stable and later. Other examples are the various Ruby
  packages which got renamed from libfoo-ruby to ruby-foo. These
  renames currently need to be tracked manually. We're planning to
  automate these. If anyone wants to help and implement it, please see
  #738172

* We've discussed whether older release information should be kept in
  the database. There are some performance issues to be considered
  since the tracker data gets rebuild with every commit, but adding
  support for oldoldstable is still well within the limits of the
  system running the Debian Security Tracker.

* debsecan is a tool which is closely related to the Security Tracker:
  It uses the tracker data and outputs a list of all open
  vulnerabilities affecting a given system. There's currently not much
  development going into debsecan since people are busy with other
  topics. If anyone is interested in joining the debsecan
  maintenance/development (there's a certain level of interest since
  several patches are submitted to the BTS), debsecan can be moved to
  collab-maint. If anyone's interested please send a mail to
  [email protected]

* We're considering to periodically send notifications of open
  vulnerabilities to maintainers. While we usually file bugs for all
  security bugs sometimes issues fall through the cracks and an
  additional reminder will be useful. We're planning to perform a test
  run and check on how to proceed from there.

* There are quite some vulnerabilities which are addressed in Debian,
  but for which no CVE identifier has been assigned. Since the CVE
  assignments are monitored by other parties, getting IDs
  assigned is useful for the open source community at large. They are
  currently tracked at
  https://security-tracker.debian.org/tracker/data/fake-names , if
  anyone is interested in coordinating CVE assignments, please get in
  touch with [email protected]

* Currently dak doesn't send out error and upload processing messages
  to uploaders to security-master. This is done to prevent information
  leaks of erroneous uploads of embargoed vulnerabilities and public
  mailing lists in the Maintainers: stanza of a package. Error
  messages will be sent to the primary email address of the PGP key of
  the uploaders (which prevents information leaks).

Security release workflow
- -------------------------

* We tried using Request Tracker for some time now. This hasn't
  worked out to our satisfaction, so we have already switched to track
  pending security updates with a text file in our Subversion
  repository. We were still using RT for non-public issues, but we're
  planning to track these in an external, private Subversion
  repository in the future. Most of the documentation has already
  been changed, a change to the developer's reference is pending.

* Historically we've included the vulnerability type and the scope of
  a security issue in our DSAs. This has become mostly redundant and
  confusing (and it's covered in the advisory text anyway), so we've
  started to no longer include these in current advisories.

* The PGP key of the security team is currently handled in a traditional
  manner. Our current key expires in September 2015 and we're planning
  to move to smart cards for managing the key in the future.

* We're currently using Subversion. We discussed changing to git, but
  git doesn't offer significant benefit for our purpose so we decided
  to stick with it. However, we're planning a rename of the repository
  which is still named after the secure-testing project which is no
  longer active and is confusing people.

* Many packages are easily testable, but some packages are more
  intricate to setup or they require special purpose hardware. We're
  planning to keep a list of willing testers, so if you're running any
  of the packages below and are available for tests, please send a
  mail to [email protected]:
  pidgin, openjdk-6, openjdk-7, drupal6, drupal7, asterisk, quagga,
  nginx, torque, openswan, roundcube, typo3, bind9, tomcat6/tomcat7,
  mediawiki and gridengine.


Security archive
- ----------------

* In order to avoid bottlenecks and to open up the security process
  further we're planning to allow maintainers which are not part of
  the security team to release security updates on their own. This
  applies to packages which have frequent vulnerabilities and where
  the maintainers are involved in the update process anyway. The exact
  details still need to be sorted out and some archive changes are
  required as well. Currently the release of a security update
  requires a login to security-master. We're planning for a mechanism
  similar to the procedure to allow upload privileges to DM;
  i.e. uploading a signed control message which triggers the actual
  update (probably with some tool like dcut). In a later step the
  advisory mail could be sent out by dak itself.

* In the past dak provided support for two distinct queues on
  security-master; one public and one for private security
  vulnerabilities. This feature is currently non-functional due to
  changes in dak development in the past, but we're planning to
  re-enable it again. This will allow us to make all public security
  updates initially available through a separate apt source prior to
  the release of a DSA (there's usually a delay between the initial
  upload of a fixed package and the release, e.g. to sort out further
  tests or to wait until all architectures are built). For non-private
  issues making this change opens to wider testing of upcoming
  security updates and furthermore earlier availability of updates for
  Debian-derived distributions based on oldstable/stable.

* We had occasional problems of mismatched tarballs between
  security-master and ftp-master. These are automatically detected and
  rejected when the security update is later merged into stable. These
  are now automatically detected and rejected when processing an
  upload to the security queue. Code which checked these during the
  upload was already available in dak and has been enabled during the
  meeting.


Others
- ------

* We're tentatively aiming for another Security Team meeting at the
  beginning of 2015. At that time Jessie will be in freeze which is a
  good opportunity to plan for jessie/jessie+1.

* In some cases the scope of security support needs to be limited (e.g
  webkit-based browsers in Wheezy) and sometimes packages need to
  end-of-lifed before the security support time frame ends. Currently
  this information needs to be retrieved from the release notes or
  announcement mails. We'd like to see a more technical solution which
  displays the unsupported packages for the installed packages on a
  specific system. If anyone wants to work on such a script, please
  contact [email protected] and we can hash out the details.

* Our documentation is currently spread across (too) many
  places. We're planning to create a one-stop site
  http://security-team.debian.org which links all information wrt to
  working/contributing on security, e.g. links to the security
  tracker, introduction information, links to useful wiki pages etc.
  Some preliminary work has already started - e.g. converting the docs
  to MarkDown.


Distribution hardening
- ----------------------

* The distribution hardening using dpkg-buildflags is coming along
  nicely. Coverage of security-sensitive packages and of all packages
  with priority:standard or above is above 95%. Some packages still
  need to be addressed or NMUed, please get in touch with
  [email protected] if you want to help out.
  Coverage of the rest of the archive is also making nice progress, if
  you're a maintainer and haven't fixed our packages yet, see
  https://wiki.debian.org/HardeningWalkthrough for more documentation.

* GCC 4.9 introduces an improved version of stack protection
  (-fstack-protector-strong). We're planning to propose this to the
  dpkg-buildflags once GCC 4.9 is the default compiler.

* We're planning to request for hidepid to be enabled by default (to 1).
  This will squash an entire class of information leaks. If you have any
  comments or objections, please get in touch with us.

* Since Wheezy the Linux kernel features a security mechanism which
  nullifies many symlink attacks (fs.protected_symlinks). We're
  planning to treat any vulnerabilities which are rendered moot by
  this protection as non-issues. If you're using custom Linux kernels
  builds you need to enable this option. kfreebsd (currently a
  technology preview) and Hurd (currently not a release arch) don't
  implement this security feature. We welcome feedback from the
  porters whether similar protections exist or whether they're
  feasible within the jessie release time frame.


LTS
- ---

* At the moment it seems likely that an extended security support
  timespan for squeeze is possible. The plan is to go ahead, sort out
  the details as as it happens, and see how this works out and whether
  it is going to be continued with wheezy.
  The rough draft is that updates will be delivered via a separate
  suite (e.g. squeeze-lts), where everyone in the Debian keyring can
  upload in order to minimise bottlenecks and allow contributions by
  all interested parties. Some packages will be exempted upfront due
  to their volatile nature (e.g. some web applications) and others
  might be expected to see important changes. The LTS suite will be
  limited to amd64 and i386. The exact procedures will be sorted out
  soon and announced in a separate mail.

* It needs to be pointed out that for this effort to be sustainable
  actual contributions by interested parties are required. squeeze-lts
  is not something that will magically fall from the sky. If you're
  dependent/interested in extended security support you should make an
  effort to contribute, either by contributing on your own or by
  paying a Debian developer/consultant to contribute for you.
  The security team itself is driving the effort, NOT doing it. Some team
  members will contribute to it individually, however.

* Anyone interested in contributing, please get in touch with
  [email protected]. We'll setup an initial coordination list
  with all interested parties. All policies / exact work will be
  sorted out there.


Full minutes can be found at http://titanpad.com/secteamessen2014 and an
archived version can be found at
http://anonscm.debian.org/viewvc/secure-testing/doc/secteamessen2014-latest.txt?view=markup



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1 -----END PGP SIGNATURE-----

Reply to:

    [email protected]
    Moritz Muehlenhoff (on-list)
    Moritz Muehlenhoff (off-list)

    Prev by Date: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
    Next by Date: Debian Contributors want YOUr data source!
    Previous by thread: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
    Next by thread: Debian Contributors want YOUr data source!
    Index(es):
        Date
        Thread