Re: Bug#1068412: apache2: CVE-2024-27316 CVE-2024-24795 CVE-2023-38709

[Raphael Hertzog]

Hi,

On Mon, 22 Apr 2024, Yadd wrote:
> Let's upload 2.4.59-1~deb10u1 ?

You might want to hold off until Thursday. Santiago requested help for a
review and Bastien Roucaries said that he would do it tomorrow
(Wednesday).

Santiago also sent your updated package through our buster ELTS staging
infrastucture and the autopkgtest of the reverse dependencies seemed OK.
So that's a good point.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: How to handle freeimage package

[Raphael Hertzog]

Hello Ola,

On Fri, 12 Apr 2024, Ola Lundqvist wrote:
> I see three:
> 1) copy secteam decision and move on to the next package (I guess
> remove from dla-needed)
> 2) copy secteam decision for most of them, but fix the ones with fedora 
> patches
> 3) dive in and start developing (that will take quite a lot of effort)
> 
> I think we should do 1 or 2 as a start. Based on all other discussions
> I'm not sure what a "consensus decision" would be.

Most of your reasoning was about "we can't fix everything as we don't have
enough resources" so we must make judgment calls and decide based on
priorities.

But here the call is relatively easy to make if you take the time to
include the data from ELTS on top of the data from LTS.

* We have an ELTS customer with this package
* There are plenty of work hours available in ELTS
* The security team has suggested we open upstream bug reports and start
  to push fixes

So please let's move on and get onto real security work. All LTS/ELTS
contributors are expected to be skilled programmers to be able to develop
fixes and submit them upstream.

Thank you.
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Guidance for CVE triage and listing packages in dla-needed.txt

[Raphael Hertzog]

Hi,

On Wed, 10 Apr 2024, Ola Lundqvist wrote:
> > Some package maintainers will typically decide to fix it via a point
> > release. But they rarely update the triaging to document "postponed" or
> > "ignored". So that's why it's up to the LTS team to make that call
> > when we are (alone) in charge of a given release.
> 
> This is a good point. I had missed that package maintainers do not
> update the security tracker. Can we have tools to help us with this?

FWIW the Debian package tracker highlight no-dsa CVE to handle and point
package maintainers to those instructions:
https://security-team.debian.org/triage.html

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Guidance for CVE triage and listing packages in dla-needed.txt

[Raphael Hertzog]

Hello,

On Tue, 09 Apr 2024, Ola Lundqvist wrote:
> Let me use some data from CVEs for last year 2023.
> I used the following method to extract the data
> grep -B 5 '\[buster\]' list | grep -A 5 "^CVE-2023-" | grep '\[buster\]'
> and then grepped for the end-of-life, not-affected (and so on to count 
> further).
> It is not a perfect method, but I think it is good enough to crunch the 
> numbers.
> 
> 1260 CVEs with tag [buster]
> 382 end-of-life
> 410 not-affected
> 281 no-dsa
> 71 postponed
> 58 ignored
> 58 fixed (most in the linux kernel)

Those numbers are quite surprising. I hope there's some error somewhere
otherwise I wonder what has been done in the 2400+ hours paid each year to
work on LTS... I'm pretty sure we have fixed more than 58 CVE. The average
month has 20 to 30 updates (see
https://lists.debian.org/debian-lts-announce/2024/03/threads.html for
example).

> A large portion of the CVEs are marked as no-dsa for a long time. We
> still have 200 of them from year 2019 for example.
> 
> And I think this is a good practice. Security is always a balance
> between a lot of things. Fixing everything will likely result in a lot
> of tools breaking.
> Also following the regular Debian Security team is also a good
> practice. They do a good job of analyzing things and we should
> normally not fix issues in buster when it will not be fixed in later
> releases. So this makes a lot of sense.

This comment still conflates "no-dsa" with "doesn't need to be fixed". We
clearly told you many times that it doesn't mean that at all.

"no-dsa" means "doesn't need to be urgently fixed, and will not be fixed
by the security team". It basically defers the question to the package
maintainer. It's up to the package maintainer to decides between
"to fix via spu", "postponed" or "ignored".

Some package maintainers will typically decide to fix it via a point
release. But they rarely update the triaging to document "postponed" or
"ignored". So that's why it's up to the LTS team to make that call
when we are (alone) in charge of a given release.

And regarding "we should normally not fix issues in buster when it will
not be fixed in later releases", we have already explained that it goes
the other way around: if we decide that something is worth to be fixed
in buster, then we should help to get it fixed in later releases.

Obviously if the sec-team triages it as unimportant/ignored, then we are
unlikely to fix it. But when the sec team opts for no-dsa, then we are
entitled to decide to fix it and we can also prepare the SPU to fix newer
releases.

> 2) Another way is to use the definition we have of
> unimportant/low/medium/high classification and use that as judgement.

I wanted to comment about this classification. While it's not in active
use by the security team, I think it would be nice if we could provide
such a classification:

1/ it can help to drive attention to the the most pressing CVE
2/ it lets us monitor how well we are performing for different severities
   (in terms of delay to provide a fix)

Clearly the LTS sponsors who are funding security work would like to see
some things like "90% of the high-priority CVE are fixed within one week".
But we are not able to provide any data.

Also we are regularly telling customers/sponsors that we are doing on own
assessment of the importance of CVE and that it may diverge from the
standard CVSS score that they use as reference. In the ideal world, we
would provide our own CVSS score with explanations but we are quite far
from this. In the mean time, it would already be great if we had more
reliable low/medium/high scoring...

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Expanding the scope (slightly) of dla-needed.txt

[Raphael Hertzog]

Hi,

On Sat, 23 Mar 2024, Roberto C. Sánchez wrote:
> In any event, I am happy to work towards reinitializing the Salsa issues
> experiment to start again in April and then see how it goes from there.
> 
> What do you think?

It's a pity that nobody else responded... I'm no longer involved in
day-to-day LTS work, but I believe this would be beneficial. Both
in terms of efficiency of the workflow, and in terms of indirectly
adding data that lets us analyze how we are performing (because
tickets are easier to introspect to make statistics about how long
we took to complete some update).

> There are also opportunities for improvement that follow from this. For
> instance, with proper use of tags, it would be possible to update the
> security tracker code so that when you are looking at the status page
> for a package, there is a section with links to Salsa issues from
> lts-team/lts-update-tasks related to that packages.

I assume this implies some per-package tags... I wonder if gitlab can
reasonably cope with several hundreds of tags. I would be tempted to just
rely on title parsing but that's details.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Expanding the scope (slightly) of dla-needed.txt

[Raphael Hertzog]

Hello Roberto,

On Thu, 14 Mar 2024, Roberto C. Sánchez wrote:
> Santiago and I are in agreement that at the moment the best available
> option is to use dla-needed.txt even for tracking work that needs to
> happen after the DLA is released, specifically working toward an upload
> to (old)stable.

Those processes can be quite long. So the entry in dla-needed might stay
around with lots of historical comments and with someone assigned that is
not actively doing anything on the package (waiting next
stable update or similar).

What happens then when a new CVE shows up for that package?

It might not show up for triaging by frontdesk because the package is
already listed... and the person assigned is not monitoring the list of
CVE of the packages since they are basically waiting the next point
release, or an answer from the security team, etc.

Thus I have fears that this change might end up with us missing to be
reactive on some updates.

Some alternative proposals to try to be constructive:

- add "foo/bullseye" or "foo/bookworm" entries to track separately the
  work on other releases (you need to check how the triaging script
  interact with that kind of entries)

- use salsa issues to track those (what happened to the experiment to use
  salsa issues for regular updates BTW?)

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: (E)LTS improved salsa pipeline support

[Raphael Hertzog]

Hi,

On Thu, 16 Mar 2023, Emilio Pozuelo Monfort wrote:
> The result is an improved pipeline with better support for both LTS and
> ELTS. [1]

Great work Emilio!

It would be nice to have all this properly documented in 
https://lts-team.pages.debian.net

I'm also curious to know if you think that some of your changes are
upstreamable, and how hard you expect this to be to stay in sync with the
upstream pipeline project?

Is it worth to document some of your design choices in case someone else
has to work on this?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Updating the LTS/ELTS instructions on freexian.com

[Raphael Hertzog]

Hello Chris, 

thanks for the report. Everything should be fixed now.

Cheers,

On Mon, 10 Oct 2022, Chris Lamb wrote:
> Hi friends,
> 
> I noticed that some of the URLs on the ELTS instructions page are now
> outdated:
> 
>   https://www.freexian.com/lts/extended/docs/how-to-use-extended-lts/
> 
> In particular, the references to:
> 
>   a) freexian-archive-keyring_2020.09.19_all.deb
>   b) archive-key.gpg
> 
> … return a 404.
> 
> "a)" simply needs updating to the latest version
> (freexian-archive-keyring_2022.06.08_all.deb), but I'm not sure what
> to do with "b)", as well as how to update these instructions in the
> first place.
> 
> 
> Regards,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org  chris-lamb.co.uk
>`-
> 

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Regression in stretch update of ruby-activerecord 2:5.2.2.1+dfsg-1+deb10u4

[Raphael Hertzog]

Hi,

On Tue, 13 Sep 2022, Abhijith PA wrote:
> > Yes, that'd make sense. I'll start a separate thread for
> > CVE-2022-32224. Roll back for now so there's no regression at least.
> 
> I've disabled patch for CVE-2022-32224. Also tested against redmine. 
> Looks good for me. Can you give a smoke test. I will upload to 
> archive.
> 
> https://people.debian.org/~abhijith/upload/fix_rails/

I upgrade to this package and the debci API is working. So from my point
of view, the regression is gone.

Don't forge to update security tracker so that CVE-2022-32224 is again
marked as unhandled.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Regression in stretch update of ruby-activerecord 2:5.2.2.1+dfsg-1+deb10u4

[Raphael Hertzog]

Hello,

On Thu, 08 Sep 2022, Abhijith PA wrote:
> On 07/09/22 11:10 AM, Raphael Hertzog wrote:
> > Hello Abhijith and the LTS team,
> > 
> > in Kali we have applied the last ruby-active* security updates and this
> > broke the web API part of autopkgtest.kali.org.
> 
> Ok, I am on it. 

Please coordinate with Utkarsh who seems to have worked on it yesterday
already.

To both of you, it would be nice to document the fact that you work on it by
adding an entry in dla-needed.txt to avoid duplicate work... fixing
regression can and should be listed too.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Regression in stretch update of ruby-activerecord 2:5.2.2.1+dfsg-1+deb10u4

[Raphael Hertzog]

Hello Abhijith and the LTS team,

in Kali we have applied the last ruby-active* security updates and this
broke the web API part of autopkgtest.kali.org.

Specifically line 51 in
/usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/coders/yaml_column.rb
makes a call to YAML.safe_load() with parameters that the YAML implementation 
in ruby 2.5 in stretch
does not support.

We have this error in our logs:

App 7518 output: 2022-09-07 07:55:07 - ArgumentError - unknown keywords: 
permitted_classes, aliases:
App 7518 output:/usr/lib/ruby/2.5.0/psych.rb:313:in `safe_load'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/coders/yaml_column.rb:51:in
 `yaml_load'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/coders/yaml_column.rb:26:in
 `load'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/type/serialized.rb:22:in
 `deserialize'
[... rest of trace at the end of the mail in case it's helpful ...]

Please fix this regression ASAP. I don't know if similar fixes have been
applied to other ruby-* packages in the same batch, in which case there
are more than a single regression.

FWIW to downgrade ruby-activerecord, I had to also downgrade ruby-activesupport
and ruby-activemodel. And it's working again now.

Regards,

Full trace:
App 7518 output: 2022-09-07 07:55:07 - ArgumentError - unknown keywords: 
permitted_classes, aliases:
App 7518 output:/usr/lib/ruby/2.5.0/psych.rb:313:in `safe_load'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/coders/yaml_column.rb:51:in
 `yaml_load'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/coders/yaml_column.rb:26:in
 `load'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/type/serialized.rb:22:in
 `deserialize'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activemodel-5.2.2.1/lib/active_model/attribute.rb:165:in
 `type_cast'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activemodel-5.2.2.1/lib/active_model/attribute.rb:42:in
 `value'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activemodel-5.2.2.1/lib/active_model/attribute_set.rb:28:in
 `transform_values'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activemodel-5.2.2.1/lib/active_model/attribute_set.rb:28:in
 `to_hash'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/attribute_methods.rb:327:in
 `attributes'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activemodel-5.2.2.1/lib/active_model/serialization.rb:129:in
 `serializable_hash'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/serialization.rb:19:in
 `serializable_hash'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activemodel-5.2.2.1/lib/active_model/serializers/json.rb:100:in
 `as_json'
App 7518 output:/usr/lib/ruby/vendor_ruby/debci/job.rb:223:in `as_json'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2.1/lib/active_support/core_ext/object/json.rb:152:in
 `block in as_json'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2.1/lib/active_support/core_ext/object/json.rb:152:in
 `map'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2.1/lib/active_support/core_ext/object/json.rb:152:in
 `as_json'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/relation/delegation.rb:71:in
 `as_json'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2.1/lib/active_support/core_ext/object/json.rb:171:in
 `block in as_json'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2.1/lib/active_support/core_ext/object/json.rb:171:in
 `each'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2.1/lib/active_support/core_ext/object/json.rb:171:in
 `map'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2.1/lib/active_support/core_ext/object/json.rb:171:in
 `as_json'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2.1/lib/active_support/json/encoding.rb:35:in
 `encode'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2.1/lib/active_support/json/encoding.rb:22:in
 `encode'
App 7518 output:
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2.1/lib/active_support/core_ext/object/json.rb:41:in
 `to_json'
App 7518 output:/usr/lib/ruby/vendor_ruby/debci/api.rb:252:in `block (2 
levels) in '
App 7518 output: 

Re: EOL candidates for security-support-ended.deb10

[Raphael Hertzog]

Hello,

On Wed, 03 Aug 2022, Sylvain Beucler wrote:
> OpenStack: we tend not to support openstack beyond upstream's support, but
> I'm having a hard time associating the components version with OpenStack's
> major version; possibly other openstack packages (horizon, manila,
> neutron...) are concerned; see also
> https://access.redhat.com/support/policy/updates/openstack/platform/ ; if
> somebody is more familiar with openstack, input would be appreciated :)
> - keystone https://lists.debian.org/debian-lts/2020/05/msg00011.html

FWIW, I got some private feedback from an LTS sponsor that they are still
running Openstack on buster so it would be nice if we could try to support
it this time around.

The number of CVE on Openstack related packages seem to be low.

Do you see any reason why we should not try to support it?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Update of debian-archive-keyring in stretch?

[Raphael Hertzog]

Hi Utkarsh,

On Tue, 14 Sep 2021, Utkarsh Gupta wrote:
> On Thu, Aug 26, 2021 at 12:33 AM Utkarsh Gupta  wrote:
> > > The missing key creates problems for example with simple-cdd:
> > > https://bugs.debian.org/992966
> >
> > Okay, I'll be happy to do the update. Though I wonder if it'd rather
> > be helpful in just doing a rebuild of buster to stretch instead of
> > backporting the changes each time?
> 
> Slight ping on this. I'm inclined towards rebuilding the same package
> for stretch. Does anybody have an opinion or opposition on this? :)
> 
> I intend to do this in the next couple of days, so let me know what
> you think.

Did you look at the differences to make up your mind before asking the
question?

I know that manually playing with jetring is not really fun but there are
a number of differences that make it likely that backporting the change
is probably safer (dependency removal, separate keyrings) to not introduce
unexpected changes.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Update of debian-archive-keyring in stretch?

[Raphael Hertzog]

[ Ccing debian-release in case they have some advice / concerns to express ]

Hello LTS team,

it would be nice if we could get an update of debian-archive-keyring
in stretch to add the bullseye key just like it has been done in buster a
while ago:
https://tracker.debian.org/news/1236764/accepted-debian-archive-keyring-20191deb10u1-source-all-into-proposed-updates-stable-new-proposed-updates/

The missing key creates problems for example with simple-cdd:
https://bugs.debian.org/992966

Thank you!
-- 
Raphaël Hertzog

Re: packages in *-lts newer than in subsequent releases

[Raphael Hertzog]

Hi,

On Mon, 23 Aug 2021, Lucas Nussbaum wrote:
> Is there a rsync mirror that could be used to sync dists/?

Not currently, no. I could look into adding it but I might not want
to make it publicly accessible. I don't really want to make it easy
to have public mirrors while ELTS has a very limited scope and
the set of supported packages changes every 6 months (so it's easy to
have a wrong impression that you are secure when most of your packages are
not supported in fact).

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Upgrade problems from LTS -> LTS+1

[Raphael Hertzog]

On Mon, 17 May 2021, Utkarsh Gupta wrote:
> > Where do you think I should include this tool and what should I name it to?
> 
> Hm, nice question :P
> Probably here: https://salsa.debian.org/freexian-team?

I would say https://salsa.debian.org/lts-team/ rather...

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Match ecosystems with limited support in debian-security-support

[Raphael Hertzog]

Hello Moritz,

On Fri, 16 Apr 2021, Moritz Mühlenhoff wrote:
> > These source package sets comes to mind:
> > - node-*
> 
> That would be super-noisy and will potentially clash with a lot of local
> package state.

Do you consider it noisy due to the possible clash with local packages?
Or are both concerns unrelated?

I agree that it would not be good to report local packages as unsupported
and we should likely find a way to avoid this. But if you assume that this
can be fixed, what is the concern?

The purpose of this package is to inform users of unsupported packages
that they have installed and it doesn't seem right to not report anything
when they have such packages.

If the concern is that the list of nose-* packages will shadow the list of
more important packages that are unsupported, maybe we can tweak the
output to list them in a single entry like "node-* (X packages
concerned)".

What do you think of this suggestion?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Support for insecure applications

[Raphael Hertzog]

Hi,

On Fri, 12 Feb 2021, Carles Pina i Estany wrote:
> When I was discussing this with a friend I had thought if Debian could
> make available and visible for the users some metrics, contextualised in
> similar (per functionality) packages:

That would certainly be useful to expose, yes!

But many things that you are listing really relate to "best practices"
for well run open source projects and there's at least one initiative to
formalize those:
https://bestpractices.coreinfrastructure.org

And you can get a badge/label. It would certainly make sense for us
to forward that kind of information to our users so that you can find
out which of the software that you're looking at have made the effort to
be structured according to best practices.

But we're getting away from the initial topic which was really focused on
the security aspect.

> May I ask: how do people choose (security wise or in general) between
> packages for a certain task? Could this be automated? Part of the

I do it a bit like you, I have no formal process.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Supporting unbound in stretch by upgrading to 1.9

[Raphael Hertzog]

Hi,

On Tue, 19 Jan 2021, Robert Edmonds wrote:
> There is an unfixed issue in Unbound 1.9.0 (#962459 / #973052) that
> affects some users (I have not been able to reproduce it). Upstream has
> invested some time in helping the Debian maintainers track down
> potential combinations of commits from later releases that may be
> related to the issue, but we were not able to produce a working,
> targeted fix. I would prefer that 1.9.0 not be exposed to more Debian
> users, especially a combination of stretch's libevent and buster's
> unbound that AFAIK has not been tested before.

Really what this means is that we need to fix unbound in buster before we
can resurrect support in stretch.

I have read the history of the two bugs and at this point I would suggest
to create a package of the latest 1.9.x and ask the tester in #962459
if that versions fixes the issue, since we have not managed to cherry-pick
a working set of commits.

Then depending on the result, work with the release team to release
that version in buster (or possibly 1.10 if really the last 1.9.x doesn't
work reliably either).

Concerning testing of unbound 1.9.x with the libevent 2.0 in stretch,
well, we have LTS users of unbound so we can ask them to test the updated
packages.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: MongoDB license change and security support

[Raphael Hertzog]

Hello,

On Wed, 25 Nov 2020, Sylvain Beucler wrote:
> Consequently I believe we're not in a position to offer MongoDB security
> support in LTS nor ELTS, and we need to drop it from our supported packages.
> 
> What do you think?

I think that you are right if you believe that we have no influence on
the upstream developers of MongoDB.

But I would suggest that we try to reach out to them to see if they are
willing to relicense security patches so that they can be used to fix old
mongodb releases explaining that it would allow distributors to keep
supporting mongodb and thus let some users continue to use mongodb instead
of switching to something else.

At the same time, we can also let them know that their new license means
that mongodb is gone from Debian and that it will hamper their ability
to attract new users (and thus money) when a large part of the webservers
run Debian-based operating systems.

So who can sheperd this? For me, the time spent on such discussions can be
made as part of your paid time. (And it puts Debian as an actor and not
only a follower, which is a good thing IMO)

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: MongoDB license change and security support

[Raphael Hertzog]

Hi,

On Wed, 25 Nov 2020, Utkarsh Gupta wrote:
> Sensing there's an agreement by others here, let's drop and announce
> this as EOL'ed then?

For LTS, definitely, yes. For ELTS, it's a bit more complicated since each
customer pays for their package list and as you noted, mongodb is among
those. I'll followup with more details privately.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Question regarding security issues in LTS/Extended LTS packages

[Raphael Hertzog]

Hello,

On Mon, 19 Oct 2020, Antoine Cervoise wrote:
> I'm not familiar with how to report security issues regarding packages
> under LTS/Extended LTS support.

LTS and ELTS have very different organizations. LTS has a public contact
point (here on this list) but ELTS doesn't have any since it's (only)
a commercial service by Freexian.

The canonical way to make sure a security issue is properly
tracked at all levels is to request a CVE.

A bug in the BTS (properly tagged "security") can help but only if you
notify the relevant security team. If they agree that your bug is a
security issue, then they can request a CVE by themselves.

> I've reported this issue on poppler-utils (included in poppler package, 
> listed here:
> https://deb.freexian.com/extended-lts/docs/supported-packages/) few months 
> ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942391.
> 
> Is this security issue supported by Extended LTS program?

Yes. But it was not on our radar because we mainly monitor CVE.

> If I found other security issues (such as this one
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944979 which is not
> supported by Extended LTS), shall I report the issue on the Debian bug
> tracker or send it here (or both)?

If the bug only concerns the old version in jessie and not any newer
version, then the correct answer is to not send it anywhere because nobody
is supporting that package right now.

You can still request a CVE for the benefit of any other security team
supporting that specific version but I'm not sure that it's worth it given
that you are specifically testing the Debian version and not the upstream
version.

Regards,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: TODO List

[Raphael Hertzog]

Hi,

On Wed, 20 May 2020, Holger Levsen wrote:
> > Is the "Find upstream developers who are willing to work on LTS support"
> > still relevant? It lists packages such as Xen, which I thought were
> > already dealt with.
> 
> yes and yes, xen is being taken care of atm. I've updated the TODO page.

Why is it still relevant? It doesn't look like that we had troubles
providing updates for the packages listed in that section, do we?

When the item was added, it was for upstream software thate were EOL
and where we didn't have the skills to prepare backports ourselves.

As long as we don't have such packages in stretch, the question is
irrelevant for me (because jessie is over mainly from a LTS point of
view).

> > Also it occurred to me that Python 2 support is disappearing, but the
> > scripts in security tracker are still Python 3 only (my latest merge
> > requests have been stalled). Not sure if we need to add this to the TODO
> > list or not.
> 
> I'd think so, though I'd defer the final decision to Raphael.

Fine for me.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Security issues in standards (ruby-openid / CVE-2019-11027)

[Raphael Hertzog]

Hi,

(Sylvain, please cc me if you want me to read something in any timely fashion)

On Thu, 07 Nov 2019, Sylvain Beucler wrote:
> Raphael, given that this package is low popcon and the vulnerability is
> fuzzy, do you know if the sponsor for this package would be willing to
> test fixes?

The sponsor is a web hoster who is listing packages used by all their
customers. I doubt that they can easily test.

I'm bccing them in case they want to chip in and express their interest
in testing fixes.

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: deb.freexian.com offline?

[Raphael Hertzog]

Hi,

On Sun, 06 Oct 2019, Markus Koschany wrote:
> Yes, there is a (DNS) problem with the server right now. We are aware of
> it and hope it will be fixed within the next 24 hours. Apologies for any
> inconveniences caused.

Server is back online. It had a problem with its network filesystem.

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/


signature.asc
Description: PGP signature

Re: Training process

[Raphael Hertzog]

Hi,

On Mon, 30 Sep 2019, Sylvain Beucler wrote:
> From what I understand there was a training during July and August,
> resulting in active status this month.
> I saw zero traces of this training besides a passing anonymous
> mention in Raphael's reports.
> Possibly we can clarify this a lil' bit? Or did I miss an information
> source?

As far as I am concerned, there's no official training. Internally, we mark
new contributors as "in-training" for the initial period where they start
to contribute on their free time to get familiar with the process.

How each contributor "gets trained" is up to them. Some will read doc and
just get it. Some will work with others that they have already met. Some
will ask questions on this mailing list, etc. But all should handle at
least one or two DLA from start to finish (with sponsors when required).

> This would also help welcome new members, I myself remember a solid
> silence when I joined (while I explicitly introduced my application at
> debian-lts@l.d.o).

I don't remember the context but answering questions to new contributors
is definitely among the things that are allowed and encouranged for paid
contributors.

Maybe your mail didn't look like a question needing an answer?

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: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Raphael Hertzog]

Hi,

On Fri, 30 Aug 2019, Alexander Wirt wrote:
> > We're not speaking of crap software, we're just speaking of software that
> > can't be maintained multiple years by backports of security patches, where
> > we get fixes only with new upstream versions (mixed with new features).
> I don't want to draw that line, someone would have decide if the software is
> just crap, the maintainer too lazy or if its really fast pacing. Wordpress is
> an example of a software that should really be supported within stable. If
> not its just crap. 
> 
> Imho we should have packages in testing that will not be part of the next
> release. And we don't want any form of automated migrations. Full stop.
> People should build and *test* their packages against stable. 

I don't know if I'm expressing myself very badly, but there's clearly a
misunderstanding.

Right now there is no "stable" release where you would build packages for
bullseye-backports. If you keep the same logic of building next release
packages against the current release, then for bullseye-backports that
would mean building packages from unstable in a testing environment.

There's usually no point in doing that because both distributions are very
close. The way to go from one one to the next is to go through britney.

To me it made sense because the split between testing and bullseye-backports
would follow the same logic as the split between stable and stable-backports:
in the former repositories you have versions of packages that can be
maintained over a long time, in the latter you have either versions of
such packages that can't be supported over multiple years or packages
for which there are no single version that can be supported multiple
years (e.g. because they are too complex and upstream supports only the latest
release).

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/


signature.asc
Description: PGP signature

Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Raphael Hertzog]

On Fri, 30 Aug 2019, Alexander Wirt wrote:
> There were several discussions over the last years. And yes, our vision of
> backports does not match the vision of those fastpace/not ready for
> stable/whatever you call them repos. In our vision debian-backports consists
> of new (tested, as in "is in testing") features from the next debian release.

"Tested as in testing" really means "tested by britney using the same
criteria as other packages" and in my earlier suggestion, I was precisely
saying that I do want to keep britney's filter between unstable
and -backports (i.e. the unused bullseye-backports
during the bullseye development cycle).

Why would it be wrong to have virtualbox or mysql or wordpress or radare2
in the -backports repo?

We're not speaking of crap software, we're just speaking of software that
can't be maintained multiple years by backports of security patches, where
we get fixes only with new upstream versions (mixed with new features).

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/


signature.asc
Description: PGP signature

Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Raphael Hertzog]

Hi,

On Fri, 30 Aug 2019, Pirate Praveen wrote:
> Fast Track repo works exactly like current backports except the packages
> are added from unstable (or experimental during transitions and freeze)
> as they cannot go to testing and hence to current backports.
> 
> As Paul noted earlier, backports team is not interested to change
> current backports criteria.

Can you point us the discussion where this got refused?

Honestly I don't like the idea of using an external service. I would like
my unstable package to migrate automatically to this new testing sibling
repository and I would like britney to control this move to ensure
consistency.

So if -backports (unused at the time where this would be 
useful
for this service!) can't be used we could find another name... but for
me it's important that it's on the main mirror and that it's controlled
by the same britney instance to ensure consistency with the main
repository.

Ideally it would be managed by the release team as a by-product of their
work on preparing the next stable release.

Or maybe we can switch the logic around. britney generates a new "rolling"
suite which includes all packages and afterwards we generate "testing" as
a subset of rolling by excluding the packages which are not supported in
stable and all their reverse dependencies. That would be even better in my
opinion.

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: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Raphael Hertzog]

(Note: pkg-security@tracker.d.o is not a valid email, dropped)

Hi,

On Thu, 29 Aug 2019, Holger Levsen wrote:
> > In general, we (Debian) don't have a good answer to this problem and
> > virtualbox is clearly a bad precedent. We really need to find a solution
> > to this in concertation with the release managers.
> 
> so I've added them to this thread.
> 
> youtube-dl is in the same boat...

To kickstart the discussion, I can try to make a proposal.

1/ We tag such packages in some way (let's say a new field
  "Backport-Only: yes")

2/ Those packages are considered like others for testing migration
   but when britney accepts them, instead of adding them to ""
   it adds them to "-backports". Obviously this requires
   britney to consider the combination of both repositories when
   considering migrations. And it will require changes to generate two
   separate output files for dak.

   The hardest part is ensuring that testing doesn't contain packages that
   would depend on packages present only in the backports part. Not sure
   we want to handle this directly within britney. It might be better to
   have QA tools for this and report bugs as appropriate.

The good thing is that those applications are then available from day 1 in
stable-backports after the release.

The backports rules would have to be tweaked a bit to accept backports
coming out of "-backports". But all those aspects are a
relatively minor detail IMO.

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/


signature.asc
Description: PGP signature

Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.

[Raphael Hertzog]

Hi,

On Thu, 29 Aug 2019, Moritz Mühlenhoff wrote:
> The upstream link makes it sound as if they are one of those upstreams
> which reject the idea of distributions shipping an older release to
> a stable distro. For a tool like radare2 that seems fair enough, so
> how about simply excluding it from stable releases (and retroactively
> drop it from Buster/Stretch in the forthcoming point releases)?


While I have no problem in getting it out of stable release, it is
important that we are able to provide backports so the package must
stay in Debian testing. 



Also radare2 is a package that we care about in Kali and we are based
on Debian testing so we would prefer if it could continue to be there.


In general, we (Debian) don't have a good answer to this problem and
virtualbox is clearly a bad precedent. We really need to find a solution
to this in concertation with the release managers.

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: Question about nss patches

[Raphael Hertzog]

Hi,

On Sun, 14 Jul 2019, Roberto C. Sánchez wrote:
> My inclination is to add the 3.26.2 patch to the nss in jessie.
> However, I wanted to ask before making that change in the event that
> there is a reason the change should not be made.
> 
> Do you have any insight you can add here?

I don't remember anything but you can lookup
https://lists.debian.org/debian-lts/2016/12/threads.html and it seems that
the security team had no CVE severe enough to justify an update at that
time.

I think you can bump to 3.26.2 if you think it's the right course of
action.

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: On (semi-)automated testing and improved workflow of LTS uploads

[Raphael Hertzog]

Hi,

On Tue, 09 Jul 2019, Jonas Meurer wrote:
> 1. Upload packages targeted at LTS suites to some dedicated place for
>automated testing
> 2. Run automatic tests (piuparts, autopkgtests, lintian?, ...)
> 3. If tests passed, publish the packages somewhere to do manual
>testing (and reviews)
> 4. (Optionally?) demand acknowledgement by a second (different) LTS
>developer
> 5. Automatically upload packages that got uploaded, passed tests and got
>second acknowledgement to the targeted LTS upload queue
> 
> While that would be very nice to have, it's probably a long way to go
> until we have such infrastructure.

If we never start to work in this direction, it will be a long way, yes
;-)

> There seems to be some agreement that the first step would be to run
> (semi-)automated tests (e.g. piuparts and autopkgtests) against the
> packages before uploading them to ${LTS}-security, i.e. point 2 of the
> list above.

Right, how do we make sure that this has been done? Shall we require that
the logs of autopkgtest/piuparts have been uploaded somewhere?

That could be the start of the above infrastructure. Have a place where
we can create "updates" and upload artifacts related to each update.

> What's your thoughts on this? Do you think that we could implement
> most/all of the desired workflow using Salsa-CI/Gitlab-CI? Or would it
> be better to build it entirely independently of Salsa - e.g. implement
> it in dak?

I believe that the service should be separate and standalone. It should
not be part of dak either.

On Thu, 11 Jul 2019, Mike Gabriel wrote:
> > 2. Run automatic tests (piuparts, autopkgtests, lintian?, ...)
> 
> Maybe, probably not lintian. As the package maintainer, at the time
> (old)oldstable (meaning the current Debian LTS) turned from testing to
> stable, might not have had their packages in shape lintian-wise. Also only
> using an old lintian would be appropriate. A recent lintian on old packages
> just creates too much noise (which we won't fix anyway).

Running lintian might be interesting... but to compare the lintian output
on the current package and on the updated package.

> > 4. (Optionally?) demand acknowledgement by a second (different) LTS
> >developer
> 
> Although demanding a second ACK adds an extra delay to our workflow, I sense
> that such a second pair of eyes peering at security patches might greatly
> improve the quality of the LTS work. Even if we don't come up with some
> auto-test engine, we should consider "peer-"reviewed uploads.

I'm not so sure about this. In some cases reviewing the patch itself and
the updated code is hard and I don't expect the reviewer to be willing to
invest that energy. But at least the reviewer can ensure that the tests
have been run, can double check whether we should add some autopkgtest
for extra safety, etc.

> > What's your thoughts on this? Do you think that we could implement
> > most/all of the desired workflow using Salsa-CI/Gitlab-CI? Or would it
> > be better to build it entirely independently of Salsa - e.g. implement
> > it in dak?
> 
> Personally, I think that using Salsa for this, adds an extra layer of
> complexity to the uploading workflow, because we have to pump all packages
> that we want to fix in LTS through GitLab.

So that means that we have to build some automation for this... that way
it could even be run by frontdesk whene it does CVE triage and add the
package to dla-needed.txt and the repository would be ready for work when
the contributors wants to work on it.

> the paid contributors. Some package uploads may even be embargoed, so
> generically, the LTS-team namespace on Salsa needs to be private (which
> excludes other contributors, also the usual package maintainers/uploaders,
> by default).

We can have a private sub-group for embargoed updates.

> As our intention is to operate on packages (not on upstream code in Git), so

We obviously work on source code... using git is not in opposition with
using an external infrastructure to review the updates. And the merge
request is the logical place where both parts meet.

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: packages from old security releases.

[Raphael Hertzog]

Hello,

On Fri, 24 May 2019, PICCORO McKAY Lenz wrote:
> well seems the ExLTS don ask for money .. the packages are free
> available and sources. so  merged in debian archive are not problem!

The reason why Wheezy Extended LTS packages are not in the Debian
repositories is because Debian was not interested in keeping the wheezy
repositories alive for longer.

So Debian is not going to merge those packages.

And while you can benefit from those packages freely, this is only
possible because there are sponsors paying the work required to provide
those updates.

See https://deb.freexian.com/extended-lts/ for details.

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: Wheezy ELTS?

[Raphael Hertzog]

On Tue, 16 Apr 2019, Paul Wise wrote:
> On Tue, Apr 16, 2019 at 10:20 AM PICCORO McKAY Lenz  wrote:
> 
> > was removed or not? are stil ELTS?
> 
> The timeline says that eLTS support ended on 31st May 2019.
> https://wiki.debian.org/LTS/Extended

That date has not passed yet and the page said clearly that it might last
longer depending on sponsors. For now it looks like that some packages
will be supported until end of 2019.

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: LTS, no-dsa reasoning and sponsored packages

[Raphael Hertzog]

Hi,

On Tue, 09 Apr 2019, Sylvain Beucler wrote:
> On 09/04/2019 09:50, Ingo Wichmann wrote:
> > labeling it "minor issues" when the real reason is "sponsors needed"
> > sounds wrong to me.
> 
> That's never been the real reason so far AFAICS, only a complementary
> reason.

Ok, still to not encourage this bad practice, please remove those
"complementary reasons" from the existing entries.

Cheres,
-- 
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: LTS, no-dsa reasoning and sponsored packages

[Raphael Hertzog]

Hi,

On Mon, 08 Apr 2019, Markus Koschany wrote:
> "Not used by any sponsor" is often used internally in commit messages as
> an additional comment, reason and clarification why a certain issue is

In commit message to which repository?

I think you are mixing the ELTS security tracker here.

> marked no-dsa or ignored, mostly intended for those people who work on
> LTS. Of course we always take into consideration how useful a fix is and
> on what we should spend our time on. This should come to no surprise to
> everyone who followed LTS in the past. Debian LTS is only possible
> because of this sponsorship and of course it is part of Debian.

FWIW, I agree fully with Salvatore that "Not used by any sponsor" is
completely irrelevant for CVE triaging.

It's relevant when paid LTS contributors have to select which packages
they are going to work on, but it's not relevant to evaluate the
importance of a CVE.

(The story is very different for ELTS, obviously)

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: Time allocation per CVE

[Raphael Hertzog]

Hi,

On Mon, 11 Mar 2019, Sylvain Beucler wrote:
> I spent the day reproducing (unbreaking) the sqlalchemy exploit,
> figuring out how to run the test suite, attempting a backport of the
> upstream fix, plus some communication.
> 
> I did about the same for the gnutls/nettle issue last week (only to
> conclude with a no-dsa T_T).
> 
> While I believe those were tricky (there's a reason why they were
> sitting for weeks), this still costs time.
> Does the above sounds a legitimate use of our sponsored time, or should
> I call it quits earlier when a fix is not straightforward?

Yes, it does sound like a legitimate use of sponsored time. We need people
who are willing to dig deeper and handle hard issues. It's fine to handle
less CVE than your peers if you regularly pick hard/long-sitting issues.

The question becomes relevant when the number of open issues starts
to increase and when we have to make choices about which issues to handle
now and which issues to postpone. But right now I think we are doing fine.

Just make sure that your hours are not wasted, i.e. document your findings
somewhere even if you decide to mark the issue no-dsa.

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: libdatetime-timezone-perl

[Raphael Hertzog]

Hi,

On Wed, 07 Nov 2018, Santiago Ruano Rincón wrote:
> I included it to dla-needed. It doesn't have any known security
> vulnerability, but its database is now out-of-date. I should be updated
> to 2018g, as it was done for stretch:
> https://tracker.debian.org/news/998425/accepted-libdatetime-timezone-perl-1209-12018g-source-into-proposed-updates-stable-new-proposed-updates/
> 
> Since there isn't point releases for LTS (we cannot propose updates for
> jessie), we have to update to jessie-security.

It might be good to add a comment explaining what's to be done in such
cases.

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/


signature.asc
Description: PGP signature

Re: Removing no-dsa entries when releasing a DLA

[Raphael Hertzog]

On Tue, 06 Nov 2018, Moritz Muehlenhoff wrote:
> On Tue, Nov 06, 2018 at 08:16:21PM +0100, Markus Koschany wrote:
> > Am 06.11.18 um 20:09 schrieb Moritz Muehlenhoff:
> > > Hi,
> > > if you fix any issues which were formerly tagged  in a DLA, make 
> > > sure
> > > to remove the no-dsa in CVE/list as well, e.g. in the DLA-1568-1 for curl.
> > 
> > I was about to do that, as usual, but when someone else does it four
> > minutes after I requested a DLA number and I still work on the commit,
> > then there is not really anything what can be done about it. I suggest
> > being a bit more patient in such cases.
> 
> Your's is just an arbitrary example, there's plenty of other cases where that
> did not happen at all until Salvatore cleaned it up.

Why is that even needed? Can't we improve the security tracker to ignore
those no-dsa tag when the CVE has been fixed? Or have some script to
remove them automatically?

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: Confusing our users - who is supporting LTS?

[Raphael Hertzog]

On Sun, 28 Oct 2018, Wouter Verhelst wrote:
> On Sun, Oct 28, 2018 at 01:14:13AM +, Ben Hutchings wrote:
> > Debian can't afford to pay developers in general, and previous
> > proposals to pay specific developers were not well received.
> 
> That was over a decade ago. The circumstances at the time were also
> different.

That's true, but it's not clear that the result would be different.

And while I have certainly no objection in going down that route,
I also don't plan to actively push into this direction given that the
current situation seems to be working relatively well. I don't want to
break what's working given the time and energy I already invested in this
project.

I know that Luca is not 100% satisfied with the current situation but
while I acknowledge his message, I have not much to propose. Last time
I tried to bring LTS even closer to Debian (in terms of getting LTS
sponsors thanked on www.debian.org, etc.), the discussions quickly stalled.

If anybody wants to drive a change in the way the LTS funding works, I
will be happy to participate in the discussion/project but it needs to be
well prepared because handling so many sponsors with all the
invoicing/payments quirks is a non-trivial amount of work and moving
away from Freexian to a trusted organization is going to be supplementary
work. The scheme has been designed so that it can fund itself (the share
that Freexian is taking funds that part of administrative work) so it's
possible and it should sustainable in the long run once the initial cost
of moving has been paid.

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: Confusing our users - who is supporting LTS?

[Raphael Hertzog]

Hi Steve,

On Tue, 23 Oct 2018, Steve McIntyre wrote:
> So I'm worried that those of us who have *not* volunteered to support
> LTS are being pressured into spending our time on it anyway. What can
> we do to fix that? How/where do we clarify for our users (and
> developers!) what LTS means, and what expectations are fair?

FWIW, I don't think that the right answer is to make LTS even more clearly
separate. We want to be able to say that Debian is supported for 5 years
and we don't want to have to put an asterisk pointing to a long list of
exceptions.

Instead we are rather aiming to integrate LTS more and more everywhere.
However, when LTS is becoming a burden on other teams, we should
definitely look how the LTS team can help to alleviate that burden.
Because as you know the LTS team has paid contributors to do that kind
of work.

I invite you to start a conversation between debian-lts and debian-cloud
to discuss how the LTS team can help you with the workload that you would
rather get rid of. Maybe we need to allocate some time each month to
update LTS images, maybe you need our help to improve your tooling to better
support LTS and that would be enough, etc. I don't know. Let's discuss.

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/


signature.asc
Description: PGP signature

Re: Wheezy update of sympa?

[Raphael Hertzog]

Hello Ola,

On Wed, 19 Sep 2018, Ola Lundqvist wrote:
> The Debian LTS team would like to fix the security issues which are
> currently open in the Wheezy version of sympa:

Wheezy is no longer the target of Debian LTS. How come that you are
sending mails about Wheezy?

"bin/contact-maintainers --lts" is doing the right thing...

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: src:wpa overlap in Debian LTS?

[Raphael Hertzog]

Hi,

On Mon, 20 Aug 2018, Holger Levsen wrote:
> I'm not sure this code is helpful as it is, because it assumes
> -needed.txt and the DLA/DSA are generated at the same time which often
> is not the case.
> 
> AIUI the code needs to check if the package for which a DLA/DSA is
> generated is present in -needed.txt.

The script removes the entry in -needed.txt, and it complains if no
changes were made in -needed.txt. This can thus only happen when
-needed.txt does not contain the entry at all.

At least that's how I understood it. I was also surprised by how
short the patch was so I tried to figure out if it was really correct. :)

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/


signature.asc
Description: PGP signature

Re: Removal of 'arm64' from debian-security repo breaks community projects

[Raphael Hertzog]

Hello,

On Fri, 17 Aug 2018, Markus Koschany wrote:
> at the moment we only support four architectures, amd64, i386, armel and
> armhf because these are the ones which were requested by users and
> sponsors of Debian's Long Term support project. I believe we would all
> love to support even more architectures in the future but this mostly
> depends on demand. Ideally this should have been discussed before the
> Jessie LTS cycle started.

Definitely. The addition of armel/armhf in wheezy was based on the demand
of Plat'Home who has been a gold sponsor for 26 months.

https://www.plathome.com/

Nobody requested the addition of arm64 so far, so this did not happen.

It's too late for Debian Jessie, at least I will not ask myself the other
Debian teams if we can re-add arm64 at this point. If someone else wants
to try this out, fine, I have no objection to include arm64 support in
Debian Jessie LTS. It certainly makes sense to support this platform
in the future.

I have updated the wiki page to make it clear that we want to consider
supporting arm64 in Debian Stretch LTS.
https://wiki.debian.org/LTS

In any case, it would be really nice to have Linaro as LTS sponsors,
you would thus be more involved in all the decision-making and you would
have had an opportunity to request arm64 support earlier.

See https://www.freexian.com/services/debian-lts.html for details.

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/


signature.asc
Description: PGP signature

Re: src:wpa overlap in Debian LTS?\

[Raphael Hertzog]

On Sat, 11 Aug 2018, Brian May wrote:
> Chris Lamb  writes:
> 
> > It would not be correct that generating a DLA would add an entry to
> > dla-needed.txt; quite the opposite as releasing a DLA ipso-facto
> > implies that the work has been completed and thus nothing is needed
> > anymore.
> 
> Maybe gen-DLA could check and warn if there is no dla-needed.txt entry?

+1

> If you want to get more paranoid, it could somehow check that the person
> matches too.

That would be hard to get right. But the script could definitely print the
name of the person who claimed the package and show it to the user.

Someone should implement all 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: News: 2018-06-01-Debian-7-Long-Term-Support-reaching-end-of-life

[Raphael Hertzog]

Hello,

On Fri, 01 Jun 2018, Markus Koschany wrote:
> > What do you think?
> 
> Fine with me. Let's do it! I will add all necessary information to
> https://wiki.debian.org/LTS/ExtendedLTS shortly.

Note that wiki janitors (Paul Wise :)) renamed the page into
https://wiki.debian.org/LTS/Extended so please update the announcement
accordingly.

Thanks everybody for handling this so constructively, it's really
appreciated.

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: Draft for EOL announcement

[Raphael Hertzog]

Hi,

On Sat, 26 May 2018, Moritz Muehlenhoff wrote:
> It's not appropriate anyway for an official Debian announcement. LTS 
> itself is already a grayish area, but advertising a service which 
> solely prepares package updates on paid basis seems not ok with DMUP.

Given that no Debian machines are involved in extended LTS, I wonder
how the DMUP comes into your picture.

I'd like to point out also that the prepared updates will be available
for all (just like for regular LTS), it's just that the set of supported
packages is solely defined by the 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: Draft for EOL announcement

[Raphael Hertzog]

Hi,

On Fri, 25 May 2018, Markus Koschany wrote:
> It is true that https://deb.freexian.com/extended-lts is not available
> yet but I assumed this will change on May 31. If not I can also delete
> the sentence about ELTS for now and add "More information will follow
> soon" or something like that. Added Raphael to CC. Hopefully he can
> clarify the situation.

Yes, I'm late, I wanted to have things ready sooner but I keep getting
distracted... but I still plan to have the above URL working at the start
of next week.

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: wheezy-security (LTS) libclamav7's version is newer than jessie's

[Raphael Hertzog]

Hello Marc,

On Thu, 03 May 2018, Marc SCHAEFER wrote:
> Probably that a downgrade of the clamav suite would solve the problem; however
> there is something wrong in the coherency between wheezy LTS and jessie, don't
> you think?

A newer version is already targeted to jessie (0.100.0+dfsg-0+deb8u1) but
it's sitting in jessie-proposed-updates and will only be in the main
repository after the next (final?) point release.

In the mean time you can add jessie-proposed-updates to your sources.list.

Maybe this should have been uploaded to jessie-updates instead...

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: linux backport in jessie LTS

[Raphael Hertzog]

On Sun, 22 Apr 2018, Ben Hutchings wrote:
> Therefore, would it make sense to add a Linux 4.9 backport to the
> regular jessie and jessie-security suites?

Yes, I think so. It's also interesting to keep a security-supported
kernel once we are past the usual 5 years of LTS (aka Extended LTS).
Since the bakcported kernel is still supported in the next release, it's
possible to continue to maintain the backport while the original kernel
version clearly went out of support.

> (Maintaining kernel backports is generally quite easy once the suite
> they are backported from is stable.)

The only downside is that you can't have a linux-latest backport in the
main suite while it was possible in the jessie-backports suite.

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: calibre / CVE-2018-7889

[Raphael Hertzog]

Hi,

On Wed, 11 Apr 2018, Antoine Beaupré wrote:
>  1. removing the package from dla-needed.txt
>  2. adding the package as unsupported in debian-security-support
>  3. (do we send end-of-life announcements to debian-lts-announce when we
>  do that?)

It's easy to mark packages as unsupported and to find many reasons to
justify this choice but we should refrain from doing so. This is
a last-resort decision and I don't think it's really warranted here.

We have a patch for the bookmark handling, let's just apply it. The
other issue about metadata can probably be ignored because it requires
the user to upload a malicious files as metadata associated to one
of its book... and it's not like the malicious file could be hidden
as a modified cover picture or something like this.

We're not short on time, let's handle it properly. While our sponsors
are mainly companies interested in server software, we strive to support
all packages and I have heard multiple times stories of desktop users who
are happy to continue to run what's in their old release.

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]

Hello,

On Tue, 20 Feb 2018, Vincent Bernat wrote:
> My bad. I suggest replacing "it would not be possible to get extended
> wheezy support" by "it would not be possible to sponsor extended wheezy
> support".

Done.

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]

(this reply on debian-lts, not on debian-devel)

On Tue, 20 Feb 2018, 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).i

FWIW, I published a blog post with more details about how it will
work from the sponsor's point of view:
https://raphaelhertzog.com/2018/02/20/time-to-join-extended-long-term-support-for-debian-7-wheezy/

Do people think that we should relay that information on
debian-lts-annou...@lists.debian.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: Fw: Extended Long Term Support for Wheezy

[Raphael Hertzog]

Hello Jens,

On Tue, 20 Feb 2018, Jens Korte wrote:
> 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.

I think it's a bit early to answer this question. It really depends
on how much of this effort is going to happen on debian.org
infrastructure.

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/

Extended Long Term Support for Wheezy

[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,
-- 
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: Better communication about spectre/meltdown

[Raphael Hertzog]

Hello,

On Thu, 08 Feb 2018, Raphael Hertzog wrote:
> I have had enquiries of LTS sponsors about the status of spectre/meltdown
> mitigations in Debian. I tried to answer but even for me as an insider who
> knows the ins and outs of Debian rather well, it's really difficult for me
> to be able to answer.
> 
> IMO we should really try to maintain a page like most vendors are doing.
> Here's what ubuntu did:
> https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown
> 
> Can we get something similar done for Debian?

No answer so far. Maybe someone should just go ahead and try to create
something like this, asking the relevant persons for the required data.

> Who is in charge of backporting the retpoline patches to our old gcc
> versions?

On IRC I learned that Moritz Muehlenhoff (jmm) started the work of
bakcporting retpoline to gcc-4.9 for jessie. We need to do the same
for gcc-4.6 (and maybe gcc-4.7) in wheezy. gcc-4.6 is used for the
kernel build so that's the important target really.

I have added items to dla-needed.txt so that someone takes care of 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/

Better communication about spectre/meltdown

[Raphael Hertzog]

Hello everybody,

I have had enquiries of LTS sponsors about the status of spectre/meltdown
mitigations in Debian. I tried to answer but even for me as an insider who
knows the ins and outs of Debian rather well, it's really difficult for me
to be able to answer.

IMO we should really try to maintain a page like most vendors are doing.
Here's what ubuntu did:
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown

Can we get something similar done for Debian?

Can someone share our plans to addresse spectre variant 1 and 2?
Have the patches matured enough at the upstream level so that they can be
considered for backporting?

Who is in charge of backporting the retpoline patches to our old gcc
versions?

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: Wheezy update of simplesamlphp?

[Raphael Hertzog]

Hi,

On Sun, 04 Feb 2018, Ola Lundqvist wrote:
> No worry. It was my mistake. I did not expect that someone else would
> do triaging when I was at front desk. You did nothing wrong. I'll try
> to be a little more observant next time. :-)

Just to be clear. Abhijith did not have to do this since he was not
assigned to frontdesk. That's the best way to avoid duplicate work.

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: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?

[Raphael Hertzog]

Hi,

On Tue, 09 Jan 2018, Brian May wrote:
> Raphael Hertzog <hert...@debian.org> writes:
> 
> > I think this mail went through the cracks as we haven't received a reply
> > from you so far. Can you let us know the status and whether we can help to
> > get the wheezy update out ?
> 
> Hello Debian-LTS team:
> 
> As we are lacking any response (yet) from Michael Shuler, I am wondering
> if we should go ahead and upload the wheezy version anyway?

Yes, please. I saw reports of failures on IRC due to missing CA
certificates.

10:07  ERROR: The certificate of `downloads.sourceforge.net' hasn't 
got a known issuer.
10:07  that still worked a few days ago :(
10:07  (on wheezy)

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: Linux kernel security release for Wheezy/Debian7 for Meltdown/Spectre mitigation

[Raphael Hertzog]

Hello Rohit,

On Sat, 06 Jan 2018, Rohit Yadav wrote:
> I would like to request a Linux kernel security patch/package for Debian
> "Wheezy" 7 (amd x86_64) for the Spectre/Meltdown security issues [1][2][3].

Please see https://lists.debian.org/debian-lts-announce/2018/01/msg4.html

This only covers Meltdown for now.

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/

About latest nasm issues found by fuzzer

[Raphael Hertzog]

Hello Cyrill,

I saw that you closed a bunch of nasm bugs found by fuzzing the 2.14rc0
codebase saying « No longer triggers with upcoming 2.13.02 (will be
released soon) »

https://bugzilla.nasm.us/show_bug.cgi?id=3392433
https://bugzilla.nasm.us/show_bug.cgi?id=3392428
https://bugzilla.nasm.us/show_bug.cgi?id=3392427
https://bugzilla.nasm.us/show_bug.cgi?id=3392426
https://bugzilla.nasm.us/show_bug.cgi?id=3392430
https://bugzilla.nasm.us/show_bug.cgi?id=3392429
https://bugzilla.nasm.us/show_bug.cgi?id=3392432

Did you ensure that the issue can also not be triggered on master?

Or are you sure that the few commits available in 2.14rc0 but not
in 2.13.02 (those merged from the "elf" branch) are not responsible of the
issues that have been identified by the fuzzer?

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: Wheezy update of ruby1.8 and ruby1.9.1?

[Raphael Hertzog]

Hello Antonio,

On Thu, 21 Dec 2017, Antonio Terceiro wrote:
> No, please go ahead. I don't have the bandwidth to handle wheezy,
> unfortunately.
> 
> It must be the third or fourth time I give this same response for
> ruby1.*.  It would be nice if the LTS team could keep track of this type
> of thing, at least to know which maintainers are able to support their
> packages on (old)oldstable and which are't, so you don't need to contact
> them every time there is an issue.
> 
> I appreciate the work that the LTS team does, but being asked something
> over and over and over is not exactly fun.

That's why we have this small paragraph in our contact mail:
> You can also opt-out from receiving future similar emails in your
> answer and then the LTS Team will take care of ruby1.9.1 updates
> for the LTS releases.

I duly noted your desire to opt-out and not be contacted again about
LTS for ruby1.8 and ruby1.9.1 (our opt-out is source package based).

You will not be contacted again.

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: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?

[Raphael Hertzog]

Hello Michael,

I think this mail went through the cracks as we haven't received a reply
from you so far. Can you let us know the status and whether we can help to
get the wheezy update out ?

Cheers,

On Mon, 23 Oct 2017, Antoine Beaupré wrote:
> On 2017-07-19 11:35:56, Michael Shuler wrote:
> > On 07/06/2017 11:13 PM, Paul Wise wrote:
> >> On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote:
> >> 
> >>> For what it's worth, my opinion is that we should attempt to synchronize
> >>> certdata.txt (and blacklist.txt, for that matter) across all suites (but
> >>> not other changes to the packaging). This would remove another decision
> >>> point in our infrastructure and ensure harmonious X509 processing across
> >>> suites.
> >> 
> >> I would like to see that happen too.
> >
> > I spent a few sessions over the past few days getting the mozilla bundle
> > 2.14 committed to all the suite branches wheezy and newer. I have some
> > more verification to work on and I'll get some packages rolled up and
> > tested for all the suites.
> >
> > I appreciate the notes here!
> 
> Hi!
> 
> Any update here? According to our records, this issue is still
> pending... I see you pushed the updates to wheezy, but didn't upload the
> results... Do you need help preparing the upload?
> 
> Thanks,
> 
> A.
> 
> -- 
> What people say, what people do, and what they say they do are
> entirely different things.
> - Margaret Mead
> 

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

Marking jasperreports as unsupported ?

[Raphael Hertzog]

Hello,

FYI I filed #884907 on debian-security-support to suggest that we mark
jasperreports as unsupported by Debian (thus not only in Wheezy). There's
a long thread in https://bugs.debian.org/880467 where its situation has
been discussed.

If you have anything to contribute to the discussion or this possible
decision, now is time to share your comments.

FTR the package is not used by any LTS sponsors AFAIK.

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/

Declaring mp3gain as unsupported

[Raphael Hertzog]

Hello,

I reviewed the case of mp3gain. Upstream development is dead (last release
in 2009). The package is only in wheezy, it's gone from jessie and newer
releases. The package is not used by any LTS sponsor.

Thus I believe that the best course of action is to not spend any time on
it and to mark the package as unsupported in debian-security-support. If
anyone disagrees, please let me know.

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: To be removed from wheezy as well

[Raphael Hertzog]

Hi,

On Tue, 19 Dec 2017, Salvatore Bonaccorso wrote:
> > Actually it got removed from wheezy in the mean time. Since it was
> > marked that way in dla-needed.txt, I pinged the ftp.d.o bug report and 
> > pinged Chris Lamb (as ftp assistant) and the package is gone from wheezy:
> > 
> > $ rmadison libnet-ping-external-perl
> > libnet-ping-external-perl | 0.13-1| oldstable-kfreebsd | source, all
> > 
> > https://tracker.debian.org/pkg/libnet-ping-external-perl
> 
> But I don't think thas worked as you might have expected, and it's not
> really gone yet. While the dak rm works, there is no point release
> mechanism for wheezy (LTS) and you still will find
> libnet-ping-external-perl in the archive (and on the mirrors), as
> there was not the usual procedure of removing the package, making a
> new release, and pushing out the updates to the mirrors.

Indeed, you are right:
rhertzog@nas:/srv/debian/mirror/dists/wheezy/main/binary-i386$ zgrep 
libnet-ping-external-perl Packages.gz
Package: libnet-ping-external-perl
Filename: 
pool/main/libn/libnet-ping-external-perl/libnet-ping-external-perl_0.13-1_all.deb

The Packages* files have not been updated since June 4th 2016. Only the Release 
file
gets regular updates.

Maybe it's time to see what is required to be able to update wheezy... I don't
think there's any technical reason behind this behaviour. It's just policy that
we don't want to touch the Packages* files except during point releases.

Given the current LTS policies, I believe that we could have unannounced point
releases that do not increment any version number... as long as we just remove
some packages.

Chris or Thorsten, could you possibly look into what it involves and see whether
it's doable on the ftpmaster side ?

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: To be removed from wheezy as well

[Raphael Hertzog]

Hello,

On Sun, 17 Dec 2017, Ola Lundqvist wrote:
> After some more reading I think removing it should be ok anyway. I'll
> change the wording from "will be removed" to "may be removed" to allow
> us the freedom to keep it if nobody takes the action to actually
> remove it.

Actually it got removed from wheezy in the mean time. Since it was
marked that way in dla-needed.txt, I pinged the ftp.d.o bug report and 
pinged Chris Lamb (as ftp assistant) and the package is gone from wheezy:

$ rmadison libnet-ping-external-perl
libnet-ping-external-perl | 0.13-1| oldstable-kfreebsd | source, all

https://tracker.debian.org/pkg/libnet-ping-external-perl

Cheers,

> On 17 December 2017 at 20:28, Ola Lundqvist  wrote:
> > Hi
> >
> > I agree that it may not be the best to remove it then. I suggest we
> > mark it as no-dsa then. Any objections?
> >
> > // Ola
> >
> > On 22 November 2017 at 21:00, Emilio Pozuelo Monfort  
> > wrote:
> >> On 08/11/17 20:19, Ola Lundqvist wrote:
> >>> Hi
> >>>
> >>> Considering that this package is about to be removed from jessie I
> >>> guess it should be removed from wheezy too. How is that done? Should I
> >>> contact the FTP maintainers about it, or do we simply ignore the
> >>> issue?
> >>
> >> We don't have point releases, so I'm not sure we can get a package removed 
> >> at
> >> this stage without extra work by the ftp masters. So our options would be:
> >>
> >> - mark as no-dsa if it's not important enough
> >> - mark as unsupported / end-of-life
> >> - fix it
> >> - get it removed
> >>
> >> The issue seems only exploitable if it's used by a service that is exposed
> >> remotely or to other issues... and has no rdeps in wheezy. OTOH there is at
> >> least one sponsor using that package. So removing it may not be the best 
> >> course
> >> given there is a proposed patch. So I'd go with either no-dsa or fix it,
> >> depending on the assessed importance.
> >>
> >> Cheers,
> >> Emilio
> >
> >
> >
> > --
> >  --- Inguza Technology AB --- MSc in Information Technology 
> > /  o...@inguza.comFolkebogatan 26\
> > |  o...@debian.org   654 68 KARLSTAD|
> > |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> > \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
> >  ---
> 
> 
> 
> -- 
>  --- Inguza Technology AB --- MSc in Information Technology 
> /  o...@inguza.comFolkebogatan 26\
> |  o...@debian.org   654 68 KARLSTAD|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
>  ---
> 

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

[SECURITY] [DLA 1207-1] erlang security update

[Raphael Hertzog]

Package: erlang
Version: 15.b.1-dfsg-4+deb7u2
CVE ID : CVE-2017-1000385

An erlang TLS server configured with cipher suites using RSA key exchange,
may be vulnerable to an Adaptive Chosen Ciphertext attack (AKA
Bleichenbacher attack) against RSA, which when exploited, may result in
plaintext recovery of encrypted messages and/or a Man-in-the-middle (MiTM)
attack, despite the attacker not having gained access to the server’s
private key itself.

For Debian 7 "Wheezy", these problems have been fixed in version
15.b.1-dfsg-4+deb7u2.

We recommend that you upgrade your erlang packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS

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


signature.asc
Description: PGP signature

Re: Wheezy update of erlang?

[Raphael Hertzog]

Hi Sergei,

On Wed, 13 Dec 2017, Sergei Golovan wrote:
> > I tried to backport the patch from version 18 for the version that we have
> > in wheezy. The resulting patch is attached. I'm not quite sure that the
> > patch is correct.
> >
> > Can you review it and test it?
> 
> I've tested unpatched version (it's vunerable indeed), and then with your 
> patch,
> and I confirm that it fixes the bug. I used the YAWS web-server with
> HTTPS enabled and https://github.com/robotattackorg/robot-detect as a
> client for testing.
> 
> So I think you can use your patch as is.

Great, thanks for your help! I'll upload the package and release
DLA-1207-1 in a few minutes.

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: Wheezy update of erlang?

[Raphael Hertzog]

Hello Sergei,

On Sun, 10 Dec 2017, Sergei Golovan wrote:
> On Sun, Dec 10, 2017 at 9:52 PM, Thorsten Alteholz  wrote:
> > Hi Sergei,
> >
> > The Debian LTS team would like to fix the security issues which are
> > currently open in the Wheezy version of erlang:
> > https://security-tracker.debian.org/tracker/source-package/erlang
> >
> > Would you like to take care of this yourself?
> 
> I would love to, but there's a problem. The existing fixes can't be applied to
> the version in wheezy because it's fairly old, and the ssl application 
> codebase
> has been changed considerably. So, basically, I'd have to recreate the
> fix myself. And I'm not sure I have time for this till next week.
> 
> Though I can test an existing patch if any.

I tried to backport the patch from version 18 for the version that we have
in wheezy. The resulting patch is attached. I'm not quite sure that the
patch is correct.

Can you review it and test it?

The package builds fine with this patch (my debdiff is also attached)
but I did not do any other test.

The binary packages for amd64 are here:
$ dget 
https://people.debian.org/~hertzog/packages/erlang_15.b.1-dfsg-4+deb7u2_amd64.changes

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/
Description: Fix CVE-2017-1000385
 This is a backport of the upstream patch on version 18.3.4.7
 which fixes the Adaptive Chosen Ciphertext attack allowing
 plaintext recovery or MITM attack.
Origin: backport, https://github.com/erlang/otp/commit/de3b9cdb8521d7edd524b4e17d1e3f883f832ec0
Last-Update: 2017-12-12

--- a/lib/ssl/src/ssl_connection.erl
+++ b/lib/ssl/src/ssl_connection.erl
@@ -75,6 +75,7 @@
 	  session_cache,% 
 	  session_cache_cb, %
   negotiated_version,   % tls_version()
+  client_hello_version, % tls_version()
   supported_protocol_versions, % [atom()]
   client_certificate_requested = false,
 	  key_algorithm,   % atom as defined by cipher_suite
@@ -416,6 +417,7 @@ hello(Hello = #client_hello{client_versi
 do_server_hello(Type, State#state{connection_states  = 
 	  ConnectionStates,
 	  negotiated_version = Version,
+	  client_hello_version = ClientVersion,
 	  session = Session});
 #alert{} = Alert ->
 handle_own_alert(Alert, ClientVersion, hello, State), 
@@ -604,10 +606,27 @@ certify(Msg, State) ->
 
 certify_client_key_exchange(#encrypted_premaster_secret{premaster_secret= EncPMS},
 			#state{negotiated_version = Version,
+   client_hello_version = {Major, Minor} = ClientVersion,
    connection_states = ConnectionStates0,
    session = Session0,
    private_key = Key} = State0) ->
-PremasterSecret = ssl_handshake:decrypt_premaster_secret(EncPMS, Key),
+%% Countermeasure for Bleichenbacher attack always provide some kind of premaster secret
+%% and fail handshake later.RFC 5246 section 7.4.7.1.
+PremasterSecret =
+try ssl_handshake:decrypt_premaster_secret(EncPMS, Key) of
+Secret when erlang:byte_size(Secret) == ?NUM_OF_PREMASTERSECRET_BYTES ->
+case Secret of
+<> -> %% Correct
+Secret;
+<> -> %% Version mismatch
+<>
+end;
+_ -> %% erlang:byte_size(Secret) =/= ?NUM_OF_PREMASTERSECRET_BYTES
+make_premaster_secret(ClientVersion, rsa)
+catch
+#alert{description = ?DECRYPT_ERROR} ->
+make_premaster_secret(ClientVersion, rsa)
+end,
 case ssl_handshake:master_secret(Version, PremasterSecret,
  ConnectionStates0, server) of
 	{MasterSecret, ConnectionStates} ->
diff -u erlang-15.b.1-dfsg/debian/changelog erlang-15.b.1-dfsg/debian/changelog
--- erlang-15.b.1-dfsg/debian/changelog
+++ erlang-15.b.1-dfsg/debian/changelog
@@ -1,3 +1,10 @@
+erlang (1:15.b.1-dfsg-4+deb7u2) wheezy-security; urgency=medium
+
+  * Fix CVE-2017-1000385: TLS server vulnerable to Adaptive Chosen Ciphertext
+attack allowing plaintext recovery of encrypted messages or MITM attack.
+
+ -- Raphaël Hertzog   Tue, 12 Dec 2017 12:16:47 +0100
+
 erlang (1:15.b.1-dfsg-4+deb7u1) stable-proposed-updates; urgency=low
 
   * Check the user, file, dir names for  and  in them in ftp module,
diff -u erlang-15.b.1-dfsg/debian/patches/series erlang-15.b.1-dfsg/debian/patches/series
--- erlang-15.b.1-dfsg/debian/patches/series
+++ erlang-15.b.1-dfsg/debian/patches/series
@@ -12,0 +13 @@
+CVE-2017-1000385.patch
only in patch2:
unchanged:
--- erlang-15.b.1-dfsg.orig/debian/patches/CVE-2017-1000385.patch
+++ erlang-15.b.1-dfsg/debian/patches/CVE-2017-1000385.patch
@@ -0,0 +1,54 @@
+Description: Fix CVE-2017-1000385
+ This is a backport of the upstream patch on version 18.3.4.7
+ which fixes the 

[SECURITY] [DLA 1205-1] simplesamlphp security update

[Raphael Hertzog]

Package: simplesamlphp
Version: 1.9.2-1+deb7u1
CVE ID : CVE-2017-12867 CVE-2017-12868 CVE-2017-12869 CVE-2017-12872
 CVE-2017-12873 CVE-2017-12874

The simplesamlphp package in wheezy is vulnerable to multiple attacks
on authentication-related code, leading to unauthorized access and
information disclosure.

CVE-2017-12867

The SimpleSAML_Auth_TimeLimitedToken class allows attackers with
access to a secret token to extend its validity period by manipulating
the prepended time offset.

CVE-2017-12869

The multiauth module allows remote attackers to bypass authentication
context restrictions and use an authentication source defined in
config/authsources.php via vectors related to improper validation of
user input.

CVE-2017-12872 / CVE-2017-12868

The (1) Htpasswd authentication source in the authcrypt module and (2)
SimpleSAML_Session class in SimpleSAMLphp 1.14.11 and earlier allow
remote iattackers to conduct timing side-channel attacks by leveraging
use of the standard comparison operator to compare secret material
against user input.

CVE-2017-12868 was a about an improper fix of CVE-2017-12872 in the
initial patch released by upstream. We have used the correct patch.

CVE-2017-12873

SimpleSAMLphp might allow attackers to obtain sensitive information,
gain unauthorized access, or have unspecified other impacts by
leveraging incorrect persistent NameID generation when an Identity
Provider (IdP) is misconfigured.

CVE-2017-12874

The InfoCard module for SimpleSAMLphp allows attackers to spoof
XML messages by leveraging an incorrect check of return values in
signature validation utilities.


For Debian 7 "Wheezy", these problems have been fixed in version
1.9.2-1+deb7u1.

We recommend that you upgrade your simplesamlphp packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS

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


signature.asc
Description: PGP signature

Re: libnet-ping-external-perl / CVE-2008-7319

[Raphael Hertzog]

Hi,

On Thu, 07 Dec 2017, Brian May wrote:
> Does anyone have any objections to me removing this? Or should I persue
> to patch option?

Given that the package has no reverse dependencies, and that it is a perl
module, i.e. not an end-user application, I believe it is fine to remove
it.

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: Wheezy update of simplesamlphp?

[Raphael Hertzog]

Hello Thijs,

On Mon, 04 Sep 2017, Thijs Kinkhorst wrote:
> On Wed, August 30, 2017 16:26, Raphael Hertzog wrote:
> > The Debian LTS team would like to fix the security issues which are
> > currently open in the Wheezy version of simplesamlphp:
> > https://security-tracker.debian.org/tracker/source-package/simplesamlphp
> >
> > Would you like to take care of this yourself?
> 
> None of this is particularly worrysome, but together an update might be
> worthwhile. I'll see what I can do.

I prepared an update fixing all CVE except CVE-2017-12870 that I marked as
ignored on wheezy because aesEncrypt/aesDecrypt in this version uses a different
implementation based on mcrypt and not openssl and it doesn't look like
worth reimplementing the fix entirely.

It would be nice if you (and/or other LTS users) could test the package (I
did absolutely no tests so far, except building the package):
$ dget 
https://people.debian.org/~hertzog/packages/simplesamlphp_1.9.2-1+deb7u1_amd64.changes

The debdiff is attached if you want to review it, too.

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/
diff -Nru simplesamlphp-1.9.2/debian/changelog 
simplesamlphp-1.9.2/debian/changelog
--- simplesamlphp-1.9.2/debian/changelog2012-08-29 17:45:36.0 
+0200
+++ simplesamlphp-1.9.2/debian/changelog2017-11-30 15:07:03.0 
+0100
@@ -1,3 +1,15 @@
+simplesamlphp (1.9.2-1+deb7u1) wheezy-security; urgency=high
+
+  * Non-maintainer upload by the Debian LTS Team.
+  * Fix CVE-2017-12867: Invalid token creation and validation
+  * Fix CVE-2017-12869: Authentication context bypass in the multiauth module
+  * Fix CVE-2017-12872: Multiple timing side-channel issues
+(use the patch fixed for CVE-2017-12868 too)
+  * Fix CVE-2017-12873: Incorrect persistent NameID generation
+  * Fix CVE-2017-12874: incorrect signature verification
+
+ -- Raphaël Hertzog <hert...@debian.org>  Thu, 30 Nov 2017 15:07:03 +0100
+
 simplesamlphp (1.9.2-1) unstable; urgency=medium
 
   * New upstream security release:
diff -Nru simplesamlphp-1.9.2/debian/patches/CVE-2017-12867.patch 
simplesamlphp-1.9.2/debian/patches/CVE-2017-12867.patch
--- simplesamlphp-1.9.2/debian/patches/CVE-2017-12867.patch 1970-01-01 
01:00:00.0 +0100
+++ simplesamlphp-1.9.2/debian/patches/CVE-2017-12867.patch 2017-11-30 
15:07:03.0 +0100
@@ -0,0 +1,17 @@
+Description: Fix CVE-2017-12867: Invalid token creation and validation
+ See https://simplesamlphp.org/security/201708-01
+Origin: backport, 
https://github.com/simplesamlphp/simplesamlphp/commit/608f24c2d5afd70c2af050785d2b12f878b33c68
+Last-Update: 2017-11-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/lib/SimpleSAML/Auth/TimeLimitedToken.php
 b/lib/SimpleSAML/Auth/TimeLimitedToken.php
+@@ -55,7 +55,7 @@ class SimpleSAML_Auth_TimeLimitedToken {
+   
+   #echo 'Calculating sha1( ' . 
$this->calculate_time_slot($offset) . ':' . $this->secretSalt . '  )';
+   
+-  return sha1( $this->calculate_time_slot($offset) . ':' . 
$this->secretSalt);
++  return sha1($offset . ':' . $this->calculate_time_slot($offset) 
. ':' . $this->secretSalt);
+   }
+   
+   /**
diff -Nru simplesamlphp-1.9.2/debian/patches/CVE-2017-12869.patch 
simplesamlphp-1.9.2/debian/patches/CVE-2017-12869.patch
--- simplesamlphp-1.9.2/debian/patches/CVE-2017-12869.patch 1970-01-01 
01:00:00.0 +0100
+++ simplesamlphp-1.9.2/debian/patches/CVE-2017-12869.patch 2017-11-30 
15:07:03.0 +0100
@@ -0,0 +1,31 @@
+From f1e485284dd428ab3cd9500c62e19c7c7234be9a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jaime=20Pe=CC=81rez=20Crespo?= <jaime.pe...@uninett.no>
+Date: Fri, 5 May 2017 11:36:42 +0200
+Subject: [PATCH] bugfix: Allow only valid auth sources in MultiAuth.
+
+The configuration of the MultiAuth authentication source specifies the auth 
sources that the user is presented with when asked for authentication. However, 
there was no proper check for the auth source selected by the user to ensure it 
is one of those allowed for MultiAuth.
+
+See https://simplesamlphp.org/security/201704-02
+
+Origin: upstream, 
https://github.com/simplesamlphp/simplesamlphp/commit/f1e485284dd428ab3cd9500c62e19c7c7234be9a
+---
+ modules/multiauth/lib/Auth/Source/MultiAuth.php | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/modules/multiauth/lib/Auth/Source/MultiAuth.php
 b/modules/multiauth/lib/Auth/Source/MultiAuth.php
+@@ -144,7 +144,13 @@ class sspmod_multiauth_Auth_Source_Multi
+   assert('is_array($state)');
+ 
+   $as = SimpleSAML_Auth_Source::getById($authId);
+-  if ($as === NULL) {
++  $valid_sources = array_map(
++  

Re: About the libreoffice CVE-2017-3157 regression

[Raphael Hertzog]

On Thu, 23 Nov 2017, Antoine Beaupré wrote:
> Now, I notice that the original advisory is about embeded data from the
> network, so maybe I'm doing things wrong and I need a weirder use
> case. In that case, I'd be happy to improve my test case to be able to
> reproduce, but otherwise we're just shooting in the dark here.

You might want to try to embed stuff from different files AIUI. You open
a writer document and paste into it stuff coming from a spreadsheet
(cells, graphics, etc.), and so on.

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: About libreoffice CVE

[Raphael Hertzog]

Hi,

On Thu, 23 Nov 2017, Antoine Beaupré wrote:
> > sal_uInt16 nLevelAnz;
> > rIn >> nLevelAnz;
> > if ( nLevelAnz > 5 )
> > {
> > OSL_FAIL( "PPTStyleSheet::Ppt-TextStylesheet hat mehr als 5 
> > Ebenen! (SJ)" );
> > nLevelAnz = 5;
> > }
> 
> I have taken on the Libreoffice DLA and I looked into this, but I didn't
> notice that check. So I backported the patch anyways. It would have been
> useful to mark CVE-2017-CVE-2017-12607 as N/A in CVE/list to avoid that 
> duplicate
> work... But I'm not sure your analysis is correct - the upstream patch
> for that issue concerns an earlier part of the code:
> 
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=334dba623dfb0c4fb2b5292c2d03741b7b33aef1
> 
> namely:
> 
> -while ( rIn.GetError() == 0 && rIn.Tell() < 
> aTxMasterStyleHd.GetRecEndFilePos() && nLev < nLevelAnz )
> +while (rIn.GetError() == 0 && rIn.Tell() < 
> aTxMasterStyleHd.GetRecEndFilePos() && nLev < nLevelAnz && nLev < 
> nMaxPPTLevels)
> 
> ... which sits about 100 lines above. Now I didn't check the upstream
> code to see if it has that check we have in wheezy, but it seems it
> won't hurt to add that patch anyways.

It can't sit 100 lines above since it's using the variable that has been
declared in the snipped that I pasted. The code I pasted is an old version
of this current code:

sal_uInt16 nLevelAnz(0);
rIn.ReadUInt16(nLevelAnz);

So I think that my analysis is correct.

> ... if we consider LTS users are only for servers, why do we bother
> supporting Libreoffice in the first place? :) It's true it can be used
> headless, but I would think the most common use case is the GUI. The
> fact that someone reported an issue (and I wonder if there's an actual
> bug report in the BTS, anyone?) shows people *are* using it that way.

Definitely, we should support libreoffice for the desktop use case.

> So we should issue a regression update. We can probably do this
> separately than a DLA for CVE-2017-12607 and CVE-2017-12608 though... In
> fact, shouldn't we *always* issue separate DLAs for regression updates?

I think it's fine to fix a regression together with other new security
vulnerabilities.

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: ASAN builds and exiv2

[Raphael Hertzog]

On Thu, 23 Nov 2017, Antoine Beaupré wrote:
> Fun times. So I'm stuck now - I reported the CVE issues upstream so
> they're at least aware of the issue:
> 
> https://github.com/Exiv2/exiv2/issues/174
> 
> ... but I am not sure what to do with the package in Wheezy. I'm tempted
> to mark this as no-dsa because there's no upstream fix and we can't
> reproduce, but I wonder if we should just mark it as not-affected
> instead.

I would like to point out that those CVE are for fuzzing issues reported
against 0.26 way before the last set of updates:
- in my previous update, many of the issues were really specific to 0.26
  and were not applicable at all to our version in wheezy
- the remaining issues have been fixed and it's quite possible that we
  have duplicate CVE here, even though the precise crash might not be the
  same (did somebody check this already?), a fix of a common underlying
  problem might have fixed multiple CVEs

Coming back to your ASAN issue, I would suggest that you try to reproduce
the issue with valgrind with 0.23-1+deb7u1 (old version). If you can
reproduce it there, then it's probably fixed by our previous update. If
you can reproduce it with 0.23-1+deb7u2 then it's still open...

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/

Wheezy update of xrdp?

[Raphael Hertzog]

Hello Dominik,

The Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of xrdp:
https://security-tracker.debian.org/tracker/CVE-2017-16927

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-lts@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of xrdp updates
for the LTS releases.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
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/

Wheezy update of otrs2?

[Raphael Hertzog]

Hello Thomas & Patrick,

The Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of otrs2:
https://security-tracker.debian.org/tracker/CVE-2017-15864
https://security-tracker.debian.org/tracker/CVE-2017-16664

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-lts@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of otrs2 updates
for the LTS releases.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
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/

Wheezy update of ohcount?

[Raphael Hertzog]

Hello Sylvestre,

The Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of ohcount:
https://security-tracker.debian.org/tracker/CVE-2017-16926

Would you like to take care of this yourself?

I tried to file an upstream bug as a first step (since there is not patch
available yet) but there is no upstream bug tracker apparently... and last
upstream activity dates back to 2010.  I pinged the project owner on
sourceforge with its integrated messaging feature but I'm not sure that I
will get any reply back.

Do you have contacts with the upstream authors ?

In any case, if you want to handle the wheezy upload, then
please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-lts@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of ohcount updates
for the LTS releases.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
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: Issue affecting php5?

[Raphael Hertzog]

Hi,

On Wed, 15 Nov 2017, Roberto C. Sánchez wrote:
> The commit was made for PHP version 5.6 and mentions CVE-2017-14107 [0].
> However, CVE-2017-14107 is only listed for libzip in the security
> tracker.  I looked at the build log and php5 in wheezy definitely builds
> the file that was modified in that commit.  My conclusion is that php5
> in wheezy embeds and builds a vulnerable version of libzip. Is it then
> correct to add php5 as being affected by that CVE in data/CVE/list?

Yes.

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: About libreoffice CVE

[Raphael Hertzog]

Hi,

On Thu, 16 Nov 2017, Emilio Pozuelo Monfort wrote:
> Well, it's there...
> 
> libreoffice (Emilio Pozuelo)
>   NOTE: regression update, see:
>   NOTE: https://lists.debian.org/debian-lts/2017/05/msg00012.html

Argh, sorry, I did not even check the entry... I only checked the output
of bin/review-update-needed which doesn't show it and the presence of CVE
made that I did not ask myself further questions.

> I really should have done that, and claimed it back if I found the time and
> energy. I have freed it now.

Thanks.

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: About libreoffice CVE

[Raphael Hertzog]

On Tue, 14 Nov 2017, Emilio Pozuelo Monfort wrote:
> Yes, that was added back then due to a regression with the fix for
> https://security-tracker.debian.org/tracker/CVE-2017-3157

When you add an entry back for some reason, please document that
reason... this entry in dla-needed.txt is useless if contributors don't
know why it sits there.

I was just assuming that it was affected by vulnerabilities and looked up
the open CVE.

> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-3157
> 
> At this point, I'm not sure what the best course of action is:
> - revert the patch, leaving LO vulnerable to the original problem
> - leave things as is, with the annoying effect of the regression, but a safe 
> LO
> - spend more time to try to fix the regression
> 
> The first option is probably unacceptable. I wonder which one of the other two
> is better at this point, given that wheezy will be EOL in a few months and 
> that
> most LTS users at this point are likely for servers.

Can you point us to the regression report that you got or saw ?

When I look at the description of the problem, I'm tempted to revert the
patch because the original problem does not look too severe. It can be
used to get private data but the information leak is limited to whatever
can appear in a preview and it requires precise knowledge of the
location of the user's document that you want to retrieve. And then
getting someone to open, modify, save a document and send it back to you
is non-trivial.

Still this looks bad so it also depends on how annoying the regression is.
Does it affect all embedded objects ?

> PS: My apologies for not dealing with this earlier. I looked at it a while ago
> but couldn't fix it, and then wasn't motivated to look at it further.

When I read "wasn't motivated to look at it further" I think that you
should have really put the package back into the queue with the
appropriate explanations.

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/

About libreoffice CVE

[Raphael Hertzog]

Hello Emilio,

as the libreoffice entry is the oldest one without update[1] I decided
to take a look at the issues (even though it's assigned to you).

For CVE-2017-12607 I believe that wheezy is not affected as the patch
shown below merely ensures that nLevelAnz does not overflow nMaxPPTLevels (= 5).
https://cgit.freedesktop.org/libreoffice/core/commit/?id=334dba623dfb0c4fb2b5292c2d03741b7b33aef1

And in the wheezy code, we already have such a check (line 4112 of
filter/source/msfilter/svdfppt.cxx):

sal_uInt16 nLevelAnz;
rIn >> nLevelAnz;
if ( nLevelAnz > 5 )
{
OSL_FAIL( "PPTStyleSheet::Ppt-TextStylesheet hat mehr als 5 
Ebenen! (SJ)" );
nLevelAnz = 5;
}

For CVE-2017-12608, the problem seems to exist as the code is very close.
Applying/backporting the patch looks trivial.

Furthermore in both cases, the commit contains a test file that could be used
to (at least manually) verify the fix.

I don't really see why this update has been stalled for so long. Please go ahead
with the update or unlock the package so that someone else can take over.

Cheers,

[1] As shown by bin/review-update-needed --lts:
Package: libreoffice
Claimed-By: Emilio Pozuelo
Claimed-Date: 2017-05-31 17:29 (166 days ago)
-- 
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: rtpproxy / CVE-2017-14114

[Raphael Hertzog]

On Mon, 06 Nov 2017, Brian May wrote:
> Why keep rtpproxy in data/dla-needed.txt if a fix is not possible?

Well, I wanted someone else to have a look at it. And also leave some
time to see if we could make an announce about possible ways to mitigate
the issue for LTS users.

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: Accepted graphicsmagick 1.3.16-1.1+deb7u10 (source amd64 all) into oldoldstable

[Raphael Hertzog]

On Tue, 31 Oct 2017, Antoine Beaupré wrote:
> I'll take care of it then. Should I just reuse the old DLA id? or
> simply mention the old DLA id in the announcement? Or mention all the
> CVEs fixed in the old DLA in the new DLA?
> 
> Not actually sure how to merge this. :)

You prepare your DLA like usual but then you also document the CVE
fixed by the old DLA in the mail sent to debian-lts-announce. But when
you generate your template with bin/gen-DLA you only pass the newly fixed
CVE (to not fix the same CVE twice in data/DLA/list).

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: Accepted graphicsmagick 1.3.16-1.1+deb7u10 (source amd64 all) into oldoldstable

[Raphael Hertzog]

On Tue, 31 Oct 2017, Antoine Beaupré wrote:
> > Please send it again and add a small sentence explaining that you send an
> > old advisory that never made it to the list... IOW if you expect
> > confusion, add an explanation to clear it up.
> 
> I will be looking at a GM update later today - should i merge that
> announcement in?

That also works, sure.

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: Accepted graphicsmagick 1.3.16-1.1+deb7u10 (source amd64 all) into oldoldstable

[Raphael Hertzog]

Hi,

On Sat, 28 Oct 2017, Brian May wrote:
> I didn't realize until after I uploaded the newer version associated
> with DLA-1140-1. So I tried sending DLA-1130-1 again, followed by
> DLA-1140-1.
> 
> Unfortunately DLA-1140-1 made it to the list, but DLA-1130-1 still
> didn't. I am concerned if I send DLA-1130-1 now that DLA-1140-1 has been
> published it would cause confusion.

Please send it again and add a small sentence explaining that you send an
old advisory that never made it to the list... IOW if you expect
confusion, add an explanation to clear it up.

But not sending the announce is not a good option IMO. FWIW checking that the
announce went through is part of my routine for each DLA.

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/

[SECURITY] [DLA 1147-1] exiv2 security update

[Raphael Hertzog]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: exiv2
Version: 0.23-1+deb7u2
CVE ID : CVE-2017-11591 CVE-2017-11683 CVE-2017-14859 CVE-2017-14862 
 CVE-2017-14864
Debian Bug : 876893

The exiv2 library is vulnerable to multiple issues that can all lead
to denial of service of the applications relying on the library to parse
images' metadata.

CVE-2017-11591

Denial of service via floating point exception in
the Exiv2::ValueType function.

CVE-2017-11683

Denial of service through failing assertion triggered by
crafted image.

CVE-2017-14859 / CVE-2017-14862 / CVE-2017-14864

Denial of service through invalid memory access triggered by a crafted
image.

For Debian 7 "Wheezy", these problems have been fixed in version
0.23-1+deb7u2.

We recommend that you upgrade your exiv2 packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS

- -- 
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/
-BEGIN PGP SIGNATURE-
Comment: Signed by Raphael Hertzog

iQEzBAEBCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAlnyFMkACgkQA4gdq+vC
mrmRmQf/R3pDU+VnZFfaWgOcGRBfwDo/WxgnhfKwvwmcihnvTp2Yt5ojwnhXS83+
BGawVQhw0w66xlkDouHV2nHBUojD2UGlIwGS7XkTaiOz4GB7wO7HNQBnNojaM2sh
5ulqACieZ88qwG2LxwurLOFJdGTfKZoQj3Z8r6WzHv/i15sgMsvsQ3QPEh4pxn/a
oXeHHFA5ESQ7eaR7/OHmICjwpju1HOHhCSWRL+ca5SebMYPCb0FZ3OnylWqfXTBl
8dZG8jgptWm+DpbzzZyt64Lj4VyCpEIohIyw4lBUIrGqZlZUPXnUapMW5Z17uDw/
GA51Co1dK4F/jDPiyhQewpP0/b4MvA==
=XU66
-END PGP SIGNATURE-

[SECURITY] [DLA 1145-1] zoneminder security update

[Raphael Hertzog]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: zoneminder
Version: 1.25.0-4+deb7u2
CVE ID : CVE-2017-5595

Multiple vulnerabilities have been found in zoneminder. This update
fixes only a serious file disclosure vulnerability (CVE-2017-5595).

The application has been found to suffer from many other problems
such as SQL injection vulnerabilities, cross-site scripting issues,
cross-site request forgery, session fixation vulnerability. Due to the
amount of issues and to the relative invasiveness of the relevant patches,
those issues will not be fixed in Wheezy. We thus advise you to restrict
access to zoneminder to trusted users only. If you want to review the
list of ignored issues, you can check the security tracker:
https://security-tracker.debian.org/tracker/source-package/zoneminder

We recommend that you upgrade your zoneminder packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS

- -- 
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/
-BEGIN PGP SIGNATURE-
Comment: Signed by Raphael Hertzog

iQEzBAEBCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAlnyCsEACgkQA4gdq+vC
mrlNNAf/YvyHZO1VnF28HRGDM4YQqS8bw1oOYBn4jQpvS2eAGdVjhhNgk696zWiD
CvVBxdls2cd40I0xA5jbXyCRljuCGztRc6aRwd2yBqjD3COBBHt7NcBq1McznR6i
9DQAHs0eRlm/Z5WbtSoh7n2MJCSXo52N4V5AqAuhFRO7a2EGxtwpVTsJhvpeRrrS
FIQ1H4dleSXITFsGOd0zzgaBNLQ1NUnzRIWv5cYQqtsil9FSO/JCPpdF0aFGBVJu
475XRM3CuJozck0wCjfgk15Z24DJ/iQseLXUUgKWxdfN3FYWkkAbW1+ohmM4Wiqe
DQRI1nJUh6gENmLdHXzu2ugk3fachQ==
=L6JT
-END PGP SIGNATURE-

[SECURITY] [DLA 1146-1] mosquitto security update

[Raphael Hertzog]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: mosquitto
Version: 0.15-2+deb7u2
CVE ID : CVE-2017-9868
Debian Bug : 865959

mosquitto's persistence file (mosquitto.db) was created in a
world-readable way thus allowing local users to obtain sensitive MQTT
topic information.  While the application has been fixed to set
proper permissions by default, you still have to manually fix
the permissions on any existing file.

For Debian 7 "Wheezy", these problems have been fixed in version
0.15-2+deb7u2.

We recommend that you upgrade your mosquitto packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS

- -- 
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/
-BEGIN PGP SIGNATURE-
Comment: Signed by Raphael Hertzog

iQEyBAEBCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAlnyB54ACgkQA4gdq+vC
mrmk1Af3YmnqEQ6UnQ1msJuq1Wv4floBLSIo7/eQ36uoIwZAOX8uMBjkEjXDO1k3
sfdfYTKbyHQK6tY5dV+8OTU/6QwhoH/k/71DNog99Y3a9RP3B0lvjjkcb7om7IEW
lgLddJhl/OrLGgySVmWcqEp4lopNxUbGZM8aMecH+7ZzgF+M2Ehl6+nncVdI5Krl
JuDd0WyU0VD0hIdw/5MzNT23Cl9M46otDKx/U8PZi2kjHJ9jHFVLqy4FVusX2Qrk
Cqc0zxqixpb+IM5iaVcyPE0V9JqJMVc0b/HreK4itVpfOQd3BPbkjDA8ZMukSu+H
kmb2PHqRg2XQEAiOQWMTIeMPhPQg
=KTO2
-END PGP SIGNATURE-

Re: Wheezy update of mosquitto?

[Raphael Hertzog]

Thanks Roger. Since this upload seems to have been forgotten, I just
made the upload and will soon release the DLA.

Cheers,

On Sun, 02 Jul 2017, Roger Light wrote:
> Hi Gianfranco,
> 
> Here you go. Build and runtime tested.
> 
> Cheers,
> 
> Roger
> 
> 
> On 2 July 2017 at 20:00, Gianfranco Costamagna  
> wrote:
> > Hello Thorsten,
> >
> >>I hope you don't mind that I added both of you to data/dla-needed.txt for
> >>the Wheezy update of mosquitto for CVE-2017-9868.
> >>
> >
> > Roger, do you want to provide debdiffs?
> >
> > thanks
> >
> > G.



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

Wheezy update of wpa?

[Raphael Hertzog]

Dear maintainer(s),

The Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of wpa:
https://security-tracker.debian.org/tracker/source-package/wpa

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-lts@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of wpa updates
for the LTS releases.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
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: Wheezy update of irssi?

[Raphael Hertzog]

Hello Lucas,

On Tue, 05 Sep 2017, Lucas Kanashiro wrote:
> The 2 CVEs that I marked as no DSA, security team did the same for
> stretch: CVE-2017-10965 e CVE-2017-1066. Probably you are talking about

Even when they are marked no-dsa, it doesn't mean that you should not fix
them. It usually means that they do not deserve a DSA on their own... but
when you push an update anyway, you should certainly include fixes for
no-dsa CVE when they are easy to fix (and unlikely to introduce
regressions).

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: About the security issues affecting python-django in Wheezy

[Raphael Hertzog]

Hello,

On Wed, 06 Sep 2017, Ola Lundqvist wrote:
> The Debian LTS team recently reviewed the security issue(s) affecting your
> package in Wheezy:
> https://security-tracker.debian.org/tracker/CVE-2017-12794

The advisory
(https://www.djangoproject.com/weblog/2017/sep/05/security-releases/) says
that Django 1.8 is unaffected. So it's likely that neither jessie nor
wheezy are affected by this issue.

Please update the tracker.

Thank you.
-- 
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: August Report

[Raphael Hertzog]

On Sun, 03 Sep 2017, Hugo Lefeuvre wrote:
>These CVEs are especially difficult to reproduce because wheezy's gcc
>doesn't have asan and reproduction conditions might require a specific
>setup.

FWIW, I have been able to reproduce quite a few issues detected by ASAN
with valgrind which does similar checks (albeit implemented in a different
way).

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/

Wheezy update of simplesamlphp?

[Raphael Hertzog]

Hello Thijs,

The Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of simplesamlphp:
https://security-tracker.debian.org/tracker/source-package/simplesamlphp

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-lts@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of simplesamlphp updates
for the LTS releases.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
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/

About the security issues affecting mpg123 in Wheezy

[Raphael Hertzog]

Hello Sebastian,

The Debian LTS team recently reviewed the security issue(s) affecting your
package in Wheezy:
https://security-tracker.debian.org/tracker/CVE-2017-12797
(and there are few other older issues that have been also ignored up to
now)

We decided that we would not prepare a wheezy security update (usually
because the security impact is low and that we concentrate our limited
resources on higher severity issues and on the most widely used packages).
That said the wheezy users would most certainly benefit from a fixed
package.

If you want to work on such an update, you're welcome to do so. Please
try to follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-lts@lists.debian.org (via a
debdiff, or with an URL pointing to the source package, or even with a
pointer to your packaging repository), and the members of the LTS team
will take care of the rest. However please make sure to submit a tested
package.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.
-- 
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/

Wheezy update of connman?

[Raphael Hertzog]

Hello Alf,

The Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of connman:
https://security-tracker.debian.org/tracker/CVE-2017-12865

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-lts@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of connman updates
for the LTS releases.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
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/

Wheezy update of git-annex?

[Raphael Hertzog]

Hello Richard,

First I want to point out that git-annex 6.20170818-1 failed to build on
arm64, you might want to ask for a give-back to retry with a newer
compiler (gcc 7.2 landed in unstable since the failed build on arm64).

Apart from that, the Debian LTS team would like to fix the security issues
which are currently open in the Wheezy version of git-annex:
https://security-tracker.debian.org/tracker/CVE-2017-12976

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-lts@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of git-annex updates
for the LTS releases.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
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/