[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Nis Martensen]

On 24-01-2018 19:37, Markus Koschany wrote:
> Thanks. How do you catch the case when security updates are part of a
> stable point release?

This requires more effort.  Does the package tracker offer a way to
query such information?  The only other idea I have right now involves
inspecting the latest entry in changelog.Debian.gz. ("Was the package
uploaded by the maintainer or one of the normal uploaders?")  Do you
have other ideas on how a user might know whether a package update
delivered in a stable point release was a security update?

Would it be feasible to make all security updates available via the
security update channel?  Then the simple suggested method would be
sufficient.  But it is probably infeasible, otherwise it would be done?

If there is no good way, maybe asking your question only for the
packages identified by the proposed method would be acceptable as a
first step, until a reliable approach is developed?


But perhaps Sandro may even be willing to accept a patch based on your
original version string pattern matching, if his other concerns are
addressed.  Sandro, what do you think?

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Am 24.01.2018 um 19:32 schrieb Nis Martensen:
> How about this?
> 
> import apt
> 
> def is_security_update(pkgname, version):
> try:
> p = apt.Cache()[pkgname]
> except:
> return False
> 
> if version not in p.versions:
> return False
> 
> if 'Debian-Security' in [o.label for o in
> p.versions[version].origins]:
> return True
> return False

Thanks. How do you catch the case when security updates are part of a
stable point release?



signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Nis Martensen]

How about this?

import apt

def is_security_update(pkgname, version):
try:
p = apt.Cache()[pkgname]
except:
return False

if version not in p.versions:
return False

if 'Debian-Security' in [o.label for o in
p.versions[version].origins]:
return True
return False

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Am 24.01.2018 um 16:56 schrieb Nis Martensen:
> Let me describe my suggestion in more detail:
> 
>  - Instead of having the "is this a security version" check
> implemented directly in bin/reportbug as a version number check, there
> could be a new function "is_security_update(package, version)" in
> reportbug/utils.py. You can move the version number check there to
> quickly decide if this is definitely no security version.
> 
>  - The point of the apt-cache idea was to try harder to avoid asking
> the user unnecessary questions. So this could be included in the new
> function. Your question will still be asked, but only if the evidence
> that the package actually is a security update is stronger.

I currently don't know how I should implement the apt-cache idea in
reportbug/utils.py. Before I start working on that I want to be assured
that this will be the final change and we can finally reach consensus.

> To avoid the sys.exit completely, you could just move the seven lines
> starting with data = r.json() inside the try: clause?

If the retrieval of distributions.json fails, the lts and security teams
will not be informed despite the fact that the user previously confirmed
"this is a regression due to a security update". Would it not be better
to quit here and let her try it again instead of continuing with the bug
report as if nothing has happened?

> 
> Please be optimistic: the feedback loop is short now, so we might
> arrive at something acceptable to Sandro soon, and then you'll have
> your notifications.

I don't see that you are listed as the maintainer or uploader of
reportbug. I appreciate your comments but if you don't make the final
decision it would be more helpful to provide the actual code.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Nis Martensen]

Let me describe my suggestion in more detail:

 - Instead of having the "is this a security version" check
implemented directly in bin/reportbug as a version number check, there
could be a new function "is_security_update(package, version)" in
reportbug/utils.py. You can move the version number check there to
quickly decide if this is definitely no security version.

 - The point of the apt-cache idea was to try harder to avoid asking
the user unnecessary questions. So this could be included in the new
function. Your question will still be asked, but only if the evidence
that the package actually is a security update is stronger.

To avoid the sys.exit completely, you could just move the seven lines
starting with data = r.json() inside the try: clause?

Please be optimistic: the feedback loop is short now, so we might
arrive at something acceptable to Sandro soon, and then you'll have
your notifications.

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Nis Martensen]

2018-01-23 15:58 GMT+01:00 Sandro Tosi :
> point releases usually include all the security updates from the
> previous point release, so they would come from the "main" repo and
> not the security one

That would only be a problem if they are then no longer available via
the security update channel. Otherwise the security source is still
listed?

> (also apt-cache policy would require to have the
> security.d.o source, which is not necessarily the case on every single
> machine)

You are right that there is no perfect solution. Could matching on
"/updates" in the suite part of the source line be a "good enough"
heuristic?

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Sandro Tosi]

On Tue, Jan 23, 2018 at 4:30 AM, Nis Martensen  wrote:
> It might be possible to determine whether an installed package is a
> security update by inspecting the output of apt-cache policy pkgname.
> Not sure if this information can also be obtained used python3-apt.

point releases usually include all the security updates from the
previous point release, so they would come from the "main" repo and
not the security one (also apt-cache policy would require to have the
security.d.o source, which is not necessarily the case on every single
machine)

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Nis Martensen]

It might be possible to determine whether an installed package is a
security update by inspecting the output of apt-cache policy pkgname.
Not sure if this information can also be obtained used python3-apt.

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Salvatore Bonaccorso]

Hi Sandro,

On Thu, Dec 28, 2017 at 08:30:34PM -0500, Sandro Tosi wrote:
> >> +if is_security_update and support != 'none':
> >> +if support == 'lts':
> >> +email_address = ['debian-...@lists.debian.org']
> >> +else:
> >> +email_address = ['t...@security.debian.org']
> >> +listcc.extend(email_address)
> >> +
> >
> > I did not had much time recently, so I'm a bit late. I would be nice
> > here if that follows as well the intention of the file with the
> > support field, that is (beware only "pseudcode"):
> >
> > [...]
> > if is_security_update and support != 'none':
> > if support == 'lts':
> > email_address = ['debian-...@lists.debian.org']
> > elif support == 'security"
> > email_address = ['t...@security.debian.org']
> > else
> > # nothing at at the moment, no more cases right now
> > [...]
> >
> > that is, in case we add another support value (you remember there was
> > once testing-security? ;-)) this can be done.
> >
> > I realize though you did now already upload the wheezy version, and
> > the unstable version as delayed, so guess we will need to leave it
> > now.
> 
> could you make it so that distributions.json contains directly the
> email address to use? do you really need the indirection of d.json ->
> support + support -> actual email (hardcoded in code)?

As stated earlier, the intention of this file will be that it is
extensible, and for a key of the suite name, having various attributes
to be exported/exposed. So yes the above can be done, and I just have
added a 'contact' field as well wich could be used instead to hardcode
the address in reportbug.

https://security-tracker.debian.org/tracker/distributions.json

carries the data now already, hope this helps already.

Regards,
Salvatore

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Sandro Tosi]

>> +if is_security_update and support != 'none':
>> +if support == 'lts':
>> +email_address = ['debian-...@lists.debian.org']
>> +else:
>> +email_address = ['t...@security.debian.org']
>> +listcc.extend(email_address)
>> +
>
> I did not had much time recently, so I'm a bit late. I would be nice
> here if that follows as well the intention of the file with the
> support field, that is (beware only "pseudcode"):
>
> [...]
> if is_security_update and support != 'none':
> if support == 'lts':
> email_address = ['debian-...@lists.debian.org']
> elif support == 'security"
> email_address = ['t...@security.debian.org']
> else
> # nothing at at the moment, no more cases right now
> [...]
>
> that is, in case we add another support value (you remember there was
> once testing-security? ;-)) this can be done.
>
> I realize though you did now already upload the wheezy version, and
> the unstable version as delayed, so guess we will need to leave it
> now.

could you make it so that distributions.json contains directly the
email address to use? do you really need the indirection of d.json ->
support + support -> actual email (hardcoded in code)?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Am 21.12.2017 um 22:42 schrieb Salvatore Bonaccorso:
[...]
> Don't worry anymore. It was as well not about all the timeline, I'm
> aware when you did the initial ping, but rather on the "we think it
> needs a change on security tracker and want this information exposed
> ... I want to do the wheezy update next week"-part.
> 
>> +if is_security_update and support != 'none':
>> +if support == 'lts':
>> +email_address = ['debian-...@lists.debian.org']
>> +else:
>> +email_address = ['t...@security.debian.org']
>> +listcc.extend(email_address)
>> +
> 
> I did not had much time recently, so I'm a bit late. I would be nice
> here if that follows as well the intention of the file with the
> support field, that is (beware only "pseudcode"):
> 
> [...]
> if is_security_update and support != 'none':
> if support == 'lts':
> email_address = ['debian-...@lists.debian.org']
> elif support == 'security"
> email_address = ['t...@security.debian.org']
> else
> # nothing at at the moment, no more cases right now
> [...] 
> 
> that is, in case we add another support value (you remember there was
> once testing-security? ;-)) this can be done.
> 
> I realize though you did now already upload the wheezy version, and
> the unstable version as delayed, so guess we will need to leave it
> now.
> 
> Thanks for doing that work, let's see how it goes when we get reports.

Hi Salvatore,

we could also avoid hardcoding the email address in reportbug and then
we would not even need such a logic. The only information I can extract
with reportbug is the release number. That's what we use as the key. The
json file could be extended with any kind of value as long this
information is preserved. At the moment I think our current solution is
"good enough" for now but if you want to change something it can be
achieved anytime. It's not even too late for Sid because the upload is
delayed until 31.12.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Salvatore Bonaccorso]

Hi Markus,

On Wed, Dec 13, 2017 at 01:34:05PM +0100, Markus Koschany wrote:
> Hi Salvatore,
> 
> Am 12.12.2017 um 07:19 schrieb Salvatore Bonaccorso:
> [...]
> > I have made the above change now live/commited. The file is still thus
> > extensible and for futher (and future use). Thanks for your work on
> > that! (as a personal note on my side, would have prefered to get less
> > pressure).
> 
> Sorry, I didn't want to put pressure on you. The email was just a
> declaration of intent to NMU reportbug in Wheezy and a last call for
> further suggestions. I haven't got a reply from Sandro yet. I filed
> #878088 on 9.10 and attached my initial patch, pinged the bug report
> again on 3.11, asked for feedback on both mailing lists on 28.11,
> incorporated requested changes in the following days and eventually send
> the final call on 10.12. I believe there was plenty of time to react. If
> there is anything to change we can always do that in a another revision.

Don't worry anymore. It was as well not about all the timeline, I'm
aware when you did the initial ping, but rather on the "we think it
needs a change on security tracker and want this information exposed
... I want to do the wheezy update next week"-part.

> +if is_security_update and support != 'none':
> +if support == 'lts':
> +email_address = ['debian-...@lists.debian.org']
> +else:
> +email_address = ['t...@security.debian.org']
> +listcc.extend(email_address)
> +

I did not had much time recently, so I'm a bit late. I would be nice
here if that follows as well the intention of the file with the
support field, that is (beware only "pseudcode"):

[...]
if is_security_update and support != 'none':
if support == 'lts':
email_address = ['debian-...@lists.debian.org']
elif support == 'security"
email_address = ['t...@security.debian.org']
else
# nothing at at the moment, no more cases right now
[...]   

that is, in case we add another support value (you remember there was
once testing-security? ;-)) this can be done.

I realize though you did now already upload the wheezy version, and
the unstable version as delayed, so guess we will need to leave it
now.

Thanks for doing that work, let's see how it goes when we get reports.

Regards,
Salvatore

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Am 13.12.2017 um 15:11 schrieb Guido Günther:
> Hi Markus,
> (trimming the cc: list a bit since this is just a minor nit):
> 
> [..snip..]
>> +for key, value in data.items():
>> +if distnumber in value['major-version']:
> 
> distnumber == value['major-version']
> 
> might be better since with distnumber = 1 it would match on 1 and 10.
> Cheers,
>  -- Guido

Hi,

true. Thanks!

Markus



signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Guido Günther]

Hi Markus,
(trimming the cc: list a bit since this is just a minor nit):

[..snip..]
> +for key, value in data.items():
> +if distnumber in value['major-version']:

distnumber == value['major-version']

might be better since with distnumber = 1 it would match on 1 and 10.
Cheers,
 -- Guido

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Hi Salvatore,

Am 12.12.2017 um 07:19 schrieb Salvatore Bonaccorso:
[...]
> I have made the above change now live/commited. The file is still thus
> extensible and for futher (and future use). Thanks for your work on
> that! (as a personal note on my side, would have prefered to get less
> pressure).

Sorry, I didn't want to put pressure on you. The email was just a
declaration of intent to NMU reportbug in Wheezy and a last call for
further suggestions. I haven't got a reply from Sandro yet. I filed
#878088 on 9.10 and attached my initial patch, pinged the bug report
again on 3.11, asked for feedback on both mailing lists on 28.11,
incorporated requested changes in the following days and eventually send
the final call on 10.12. I believe there was plenty of time to react. If
there is anything to change we can always do that in a another revision.

> For jessie and stretch: such an update should go in via a point
> release (like for the debian-security-support package updates). We
> have not heard anything yet on the implementation side from the
> maintainer, Sandro, did you got Markus updates/proposals? Your input
> would be very appreciated :)

I intend to submit a new version of reportbug with my patch (attached)
for Jessie and Stretch next week.

Regards,

Markus
diff -Nru reportbug-7.1.7/bin/reportbug reportbug-7.1.7/bin/reportbug
--- reportbug-7.1.7/bin/reportbug   2017-05-29 22:00:17.0 +0200
+++ reportbug-7.1.7/bin/reportbug   2017-05-29 22:00:17.0 +0200
@@ -32,6 +32,8 @@
 import optparse
 import re
 import locale
+import requests
+import json
 import subprocess
 import shlex
 import email
@@ -1926,6 +1928,33 @@
 listcc += ui.get_multiline(
 'Enter any additional addresses this report should be sent to; 
press ENTER after each address.')
 
+# If the bug is reported against a package with a version that
+# indicates a security update add the security or lts team to CC
+# after user confirmation
+is_security_update = False
+if pkgversion:
+regex = re.compile('(\+|~)deb(\d+)u(\d+)')
+secversion = regex.search(pkgversion)
+if secversion:
+if ui.yes_no('Do you want to report a regression because of a 
security update? ',
+ 'Yes, please inform the LTS and security teams.',
+ 'No or I am not sure.', True):
+is_security_update = True
+distnumber = secversion[2]
+r = 
requests.get('https://security-tracker.debian.org/tracker/distributions.json')
+data = r.json()
+support = 'none'
+for key, value in data.items():
+if distnumber in value['major-version']:
+support = value['support']
+
+if is_security_update and support != 'none':
+if support == 'lts':
+email_address = ['debian-...@lists.debian.org']
+else:
+email_address = ['t...@security.debian.org']
+listcc.extend(email_address)
+
 if severity and rtype:
 severity = debbugs.convert_severity(severity, rtype)


signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Salvatore Bonaccorso]

Hi Markus,

On Sun, Dec 10, 2017 at 03:58:30PM +0100, Markus Koschany wrote:
> Am 10.12.2017 um 13:35 schrieb Salvatore Bonaccorso:
> [...]
> >>> and beeing accessible under 
> >>> https://security-tracker.debian.org/tracker/distributions.json
> >>
> >> That makes as lot of sense! (I used YAML in the example for readability,
> >> output of the tracker should be JSON). The main reason why I'd prefer
> >> the tracker is that we can update the file ourselves when switching
> >> releases.
> > 
> > Yes I can understand why you prefer the security-tracker itself. My
> > convern was (and still in back on my head), we add more mappings. But
> > with eabove, we do not need to take care of stable->oldstable, etc ...
> > just add the who-is-supporting field.
> > 
> > A version of the above is live on the security-tracker, but I have not
> > yet commited the changes. I would first like to know: are you happy
> > with the 'major-version' nomenclature, otherwise we could change it to
> > 'version'. 'support' should maybe 'support-by'?
> 
> Hi,
> 
> IMO my version of distributions.json did the same thing. We only can
> deduce the version from the package, so the version was the key and the
> values were "lts", "oldstable", "stable". Everything else is not supported.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=878088;filename=distribution.json;msg=45
> 
> For the next LTS this file would look like
> 
> 8: "lts"
> 9: "stable"
> 
> and then
> 
> 8: "lts"
> 9: "oldstable"
> 10: "stable"
> 
> 
> More information is not required. The code looks like that:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=878088;filename=reportbug.debdiff;msg=45
> 
> 
> Of course I can also use the new json file. If I don't hear any further
> objections I am going to use
> 
> https://security-tracker.debian.org/tracker/distributions.json
> 
> from now on. I intend to release an update of reportbug for Wheezy next
> week. Please contact me if you are interested in an upgrade for Jessie
> and Stretch as well.

I have made the above change now live/commited. The file is still thus
extensible and for futher (and future use). Thanks for your work on
that! (as a personal note on my side, would have prefered to get less
pressure).

For jessie and stretch: such an update should go in via a point
release (like for the debian-security-support package updates). We
have not heard anything yet on the implementation side from the
maintainer, Sandro, did you got Markus updates/proposals? Your input
would be very appreciated :)

Regards,
Salvatore

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Guido Günther]

Hi,
On Sun, Dec 10, 2017 at 01:35:43PM +0100, Salvatore Bonaccorso wrote:
> Hi Guido,
> 
> On Sun, Dec 10, 2017 at 12:59:05PM +0100, Guido Günther wrote:
> > Hi,
> > On Sun, Dec 10, 2017 at 12:51:38PM +0100, Salvatore Bonaccorso wrote:
> > > Hi
> > > 
> > > On Sun, Dec 10, 2017 at 10:00:55AM +0100, Salvatore Bonaccorso wrote:
> > > > Hi
> > > > 
> > > > Cc'ing explicitly Guido and Raphael, who commented before.
> > > > 
> > > > On Sat, Dec 09, 2017 at 03:25:14PM +0100, Markus Koschany wrote:
> > > > > Hi,
> > > > > 
> > > > > I have updated my patch for reportbug. Now emails are sent only to one
> > > > > of the team mailing lists based on the release number in the version
> > > > > string. There is apparently no simple way to determine the 
> > > > > relationship
> > > > > between release number, code name, suite and whether this is a LTS
> > > > > release. So we came up with a simple json file which provides this 
> > > > > kind
> > > > > of information and can be adjusted as time goes by. We think that
> > > > > security-tracker.debian.org would be a good place for this file but 
> > > > > I'd
> > > > > appreciate it if someone from the security team told us the exact 
> > > > > location.
> > > > > 
> > > > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088#45
> > > > 
> > > > So let me first understand the information you would need from that
> > > > file (here in sort-of-yaml):
> > > > 
> > > > cut-cut-cut-cut-cut-cut-
> > > > wheezy:
> > > >   major-version: 7
> > > >   support: lts
> > > > jessie:
> > > >   major-version: 8
> > > >   support: security
> > > > stretch:
> > > >   major-version: 9
> > > >   support: security
> > > > buster:
> > > >   major-version: 10
> > > >   support: none
> > > > bullseye:
> > > >   major-version: 11
> > > >   support: none
> > > > cut-cut-cut-cut-cut-cut-
> > > 
> > > But rather in JSON than YAML. Florian would not recommend using YAML, and
> > > furthermore it's more consistent with the tracker itself.
> > > 
> > > cut-cut-cut-cut-cut-cut-
> > > {
> > >   "wheezy": {
> > > "major-version": "7",
> > > "support": "lts"
> > >   },
> > >   "jessie": {
> > > "major-version": "8",
> > > "support": "security"
> > >   },
> > >   "stretch": {
> > > "major-version": "9",
> > > "support": "security"
> > >   },
> > >   "buster": {
> > > "major-version": "10",
> > > "support": "none"
> > >   },
> > >   "bullseye": {
> > > "major-version": "11",
> > > "support": "none"
> > >   }
> > > }
> > > cut-cut-cut-cut-cut-cut-
> > > 
> > > and beeing accessible under 
> > > https://security-tracker.debian.org/tracker/distributions.json
> > 
> > That makes as lot of sense! (I used YAML in the example for readability,
> > output of the tracker should be JSON). The main reason why I'd prefer
> > the tracker is that we can update the file ourselves when switching
> > releases.
> 
> Yes I can understand why you prefer the security-tracker itself. My
> convern was (and still in back on my head), we add more mappings. But
> with eabove, we do not need to take care of stable->oldstable, etc ...
> just add the who-is-supporting field.
> 
> A version of the above is live on the security-tracker, but I have not
> yet commited the changes. I would first like to know: are you happy
> with the 'major-version' nomenclature, otherwise we could change it to
> 'version'. 'support' should maybe 'support-by'?

Looks good to me.
Cheers,
 -- Guido

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Am 10.12.2017 um 13:35 schrieb Salvatore Bonaccorso:
[...]
>>> and beeing accessible under 
>>> https://security-tracker.debian.org/tracker/distributions.json
>>
>> That makes as lot of sense! (I used YAML in the example for readability,
>> output of the tracker should be JSON). The main reason why I'd prefer
>> the tracker is that we can update the file ourselves when switching
>> releases.
> 
> Yes I can understand why you prefer the security-tracker itself. My
> convern was (and still in back on my head), we add more mappings. But
> with eabove, we do not need to take care of stable->oldstable, etc ...
> just add the who-is-supporting field.
> 
> A version of the above is live on the security-tracker, but I have not
> yet commited the changes. I would first like to know: are you happy
> with the 'major-version' nomenclature, otherwise we could change it to
> 'version'. 'support' should maybe 'support-by'?

Hi,

IMO my version of distributions.json did the same thing. We only can
deduce the version from the package, so the version was the key and the
values were "lts", "oldstable", "stable". Everything else is not supported.

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=878088;filename=distribution.json;msg=45

For the next LTS this file would look like

8: "lts"
9: "stable"

and then

8: "lts"
9: "oldstable"
10: "stable"


More information is not required. The code looks like that:

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=878088;filename=reportbug.debdiff;msg=45


Of course I can also use the new json file. If I don't hear any further
objections I am going to use

https://security-tracker.debian.org/tracker/distributions.json

from now on. I intend to release an update of reportbug for Wheezy next
week. Please contact me if you are interested in an upgrade for Jessie
and Stretch as well.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Salvatore Bonaccorso]

Hi Guido,

On Sun, Dec 10, 2017 at 12:59:05PM +0100, Guido Günther wrote:
> Hi,
> On Sun, Dec 10, 2017 at 12:51:38PM +0100, Salvatore Bonaccorso wrote:
> > Hi
> > 
> > On Sun, Dec 10, 2017 at 10:00:55AM +0100, Salvatore Bonaccorso wrote:
> > > Hi
> > > 
> > > Cc'ing explicitly Guido and Raphael, who commented before.
> > > 
> > > On Sat, Dec 09, 2017 at 03:25:14PM +0100, Markus Koschany wrote:
> > > > Hi,
> > > > 
> > > > I have updated my patch for reportbug. Now emails are sent only to one
> > > > of the team mailing lists based on the release number in the version
> > > > string. There is apparently no simple way to determine the relationship
> > > > between release number, code name, suite and whether this is a LTS
> > > > release. So we came up with a simple json file which provides this kind
> > > > of information and can be adjusted as time goes by. We think that
> > > > security-tracker.debian.org would be a good place for this file but I'd
> > > > appreciate it if someone from the security team told us the exact 
> > > > location.
> > > > 
> > > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088#45
> > > 
> > > So let me first understand the information you would need from that
> > > file (here in sort-of-yaml):
> > > 
> > > cut-cut-cut-cut-cut-cut-
> > > wheezy:
> > >   major-version: 7
> > >   support: lts
> > > jessie:
> > >   major-version: 8
> > >   support: security
> > > stretch:
> > >   major-version: 9
> > >   support: security
> > > buster:
> > >   major-version: 10
> > >   support: none
> > > bullseye:
> > >   major-version: 11
> > >   support: none
> > > cut-cut-cut-cut-cut-cut-
> > 
> > But rather in JSON than YAML. Florian would not recommend using YAML, and
> > furthermore it's more consistent with the tracker itself.
> > 
> > cut-cut-cut-cut-cut-cut-
> > {
> >   "wheezy": {
> > "major-version": "7",
> > "support": "lts"
> >   },
> >   "jessie": {
> > "major-version": "8",
> > "support": "security"
> >   },
> >   "stretch": {
> > "major-version": "9",
> > "support": "security"
> >   },
> >   "buster": {
> > "major-version": "10",
> > "support": "none"
> >   },
> >   "bullseye": {
> > "major-version": "11",
> > "support": "none"
> >   }
> > }
> > cut-cut-cut-cut-cut-cut-
> > 
> > and beeing accessible under 
> > https://security-tracker.debian.org/tracker/distributions.json
> 
> That makes as lot of sense! (I used YAML in the example for readability,
> output of the tracker should be JSON). The main reason why I'd prefer
> the tracker is that we can update the file ourselves when switching
> releases.

Yes I can understand why you prefer the security-tracker itself. My
convern was (and still in back on my head), we add more mappings. But
with eabove, we do not need to take care of stable->oldstable, etc ...
just add the who-is-supporting field.

A version of the above is live on the security-tracker, but I have not
yet commited the changes. I would first like to know: are you happy
with the 'major-version' nomenclature, otherwise we could change it to
'version'. 'support' should maybe 'support-by'?

Regards,
Salvatore

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Guido Günther]

Hi,
On Sun, Dec 10, 2017 at 12:51:38PM +0100, Salvatore Bonaccorso wrote:
> Hi
> 
> On Sun, Dec 10, 2017 at 10:00:55AM +0100, Salvatore Bonaccorso wrote:
> > Hi
> > 
> > Cc'ing explicitly Guido and Raphael, who commented before.
> > 
> > On Sat, Dec 09, 2017 at 03:25:14PM +0100, Markus Koschany wrote:
> > > Hi,
> > > 
> > > I have updated my patch for reportbug. Now emails are sent only to one
> > > of the team mailing lists based on the release number in the version
> > > string. There is apparently no simple way to determine the relationship
> > > between release number, code name, suite and whether this is a LTS
> > > release. So we came up with a simple json file which provides this kind
> > > of information and can be adjusted as time goes by. We think that
> > > security-tracker.debian.org would be a good place for this file but I'd
> > > appreciate it if someone from the security team told us the exact 
> > > location.
> > > 
> > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088#45
> > 
> > So let me first understand the information you would need from that
> > file (here in sort-of-yaml):
> > 
> > cut-cut-cut-cut-cut-cut-
> > wheezy:
> >   major-version: 7
> >   support: lts
> > jessie:
> >   major-version: 8
> >   support: security
> > stretch:
> >   major-version: 9
> >   support: security
> > buster:
> >   major-version: 10
> >   support: none
> > bullseye:
> >   major-version: 11
> >   support: none
> > cut-cut-cut-cut-cut-cut-
> 
> But rather in JSON than YAML. Florian would not recommend using YAML, and
> furthermore it's more consistent with the tracker itself.
> 
> cut-cut-cut-cut-cut-cut-
> {
>   "wheezy": {
> "major-version": "7",
> "support": "lts"
>   },
>   "jessie": {
> "major-version": "8",
> "support": "security"
>   },
>   "stretch": {
> "major-version": "9",
> "support": "security"
>   },
>   "buster": {
> "major-version": "10",
> "support": "none"
>   },
>   "bullseye": {
> "major-version": "11",
> "support": "none"
>   }
> }
> cut-cut-cut-cut-cut-cut-
> 
> and beeing accessible under 
> https://security-tracker.debian.org/tracker/distributions.json

That makes as lot of sense! (I used YAML in the example for readability,
output of the tracker should be JSON). The main reason why I'd prefer
the tracker is that we can update the file ourselves when switching
releases.
Cheers,
 -- Guido

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Salvatore Bonaccorso]

Hi

On Sun, Dec 10, 2017 at 10:00:55AM +0100, Salvatore Bonaccorso wrote:
> Hi
> 
> Cc'ing explicitly Guido and Raphael, who commented before.
> 
> On Sat, Dec 09, 2017 at 03:25:14PM +0100, Markus Koschany wrote:
> > Hi,
> > 
> > I have updated my patch for reportbug. Now emails are sent only to one
> > of the team mailing lists based on the release number in the version
> > string. There is apparently no simple way to determine the relationship
> > between release number, code name, suite and whether this is a LTS
> > release. So we came up with a simple json file which provides this kind
> > of information and can be adjusted as time goes by. We think that
> > security-tracker.debian.org would be a good place for this file but I'd
> > appreciate it if someone from the security team told us the exact location.
> > 
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088#45
> 
> So let me first understand the information you would need from that
> file (here in sort-of-yaml):
> 
> cut-cut-cut-cut-cut-cut-
> wheezy:
>   major-version: 7
>   support: lts
> jessie:
>   major-version: 8
>   support: security
> stretch:
>   major-version: 9
>   support: security
> buster:
>   major-version: 10
>   support: none
> bullseye:
>   major-version: 11
>   support: none
> cut-cut-cut-cut-cut-cut-

But rather in JSON than YAML. Florian would not recommend using YAML, and
furthermore it's more consistent with the tracker itself.

cut-cut-cut-cut-cut-cut-
{
  "wheezy": {
"major-version": "7",
"support": "lts"
  },
  "jessie": {
"major-version": "8",
"support": "security"
  },
  "stretch": {
"major-version": "9",
"support": "security"
  },
  "buster": {
"major-version": "10",
"support": "none"
  },
  "bullseye": {
"major-version": "11",
"support": "none"
  }
}
cut-cut-cut-cut-cut-cut-

and beeing accessible under 
https://security-tracker.debian.org/tracker/distributions.json

Regards,
Salvatore

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Salvatore Bonaccorso]

Hi

Cc'ing explicitly Guido and Raphael, who commented before.

On Sat, Dec 09, 2017 at 03:25:14PM +0100, Markus Koschany wrote:
> Hi,
> 
> I have updated my patch for reportbug. Now emails are sent only to one
> of the team mailing lists based on the release number in the version
> string. There is apparently no simple way to determine the relationship
> between release number, code name, suite and whether this is a LTS
> release. So we came up with a simple json file which provides this kind
> of information and can be adjusted as time goes by. We think that
> security-tracker.debian.org would be a good place for this file but I'd
> appreciate it if someone from the security team told us the exact location.
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088#45

So let me first understand the information you would need from that
file (here in sort-of-yaml):

cut-cut-cut-cut-cut-cut-
wheezy:
  major-version: 7
  support: lts
jessie:
  major-version: 8
  support: security
stretch:
  major-version: 9
  support: security
buster:
  major-version: 10
  support: none
bullseye:
  major-version: 11
  support: none
cut-cut-cut-cut-cut-cut-

For reportbug I do not see a need for the alias mapping, so we should
not add it it yet, or why would you need to know that wheezy is
oldoldstable for it? AFAICS, what you need for is a value to decide if
it's lts or security team supported, that is what I'm aiming for in
the above format with the support field. Once jessie moves to lts
supported, we just need to update that value. Then on reportbug side,
if the support is for lts, X-Debbugs-CC the debian-lts list, if it's
support 'security', X-Debbugs-CC the security team.

Possibly we could add a static file exporting this information on the
security-tracker which only would be needed to extend once a suite
goes over to lts support and new known releases are added. Then could
be available under
https://security-tracker.debian.org/tracker/distributions.yaml

How does your current patch for reportbug look like?

Please add my on Cc directly for replies.

Regards,
Salvatore

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Guido Günther]

Hi,
On Sat, Dec 09, 2017 at 03:28:09PM +0100, Markus Koschany wrote:
> Am 09.12.2017 um 15:21 schrieb Guido Günther:
> [...]
> > Looks good in principle. I would use a slightly different json format
> > though (using YAML for readability):
> > 
> > wheezy:
> >major: 7
> >alias: oldoldstable   
> > jessy:
> >major: 8
> >alias: oldstable
> > stretch:
> >major: 9
> >alias: stable 
> > 
> > This allows us to extend this in the future if necessary.
> > Cheers,
> >  -- Guido
> 
> Ok, that shouldn't be a problem. Now I just need to know where I should
> put this file then I could upload a new version of reportbug to wheezy
> next week.

I would add this to the tracker (but Salvatore (cc:) had some concerns). See
svn+ssh://svn.debian.org/svn/secure-testing@39406 for an
example.

Cheers,
 -- Guido

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Am 09.12.2017 um 15:21 schrieb Guido Günther:
[...]
> Looks good in principle. I would use a slightly different json format
> though (using YAML for readability):
> 
> wheezy:
>major: 7
>alias: oldoldstable   
> jessy:
>major: 8
>alias: oldstable
> stretch:
>major: 9
>alias: stable 
> 
> This allows us to extend this in the future if necessary.
> Cheers,
>  -- Guido

Ok, that shouldn't be a problem. Now I just need to know where I should
put this file then I could upload a new version of reportbug to wheezy
next week.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Hi,

I have updated my patch for reportbug. Now emails are sent only to one
of the team mailing lists based on the release number in the version
string. There is apparently no simple way to determine the relationship
between release number, code name, suite and whether this is a LTS
release. So we came up with a simple json file which provides this kind
of information and can be adjusted as time goes by. We think that
security-tracker.debian.org would be a good place for this file but I'd
appreciate it if someone from the security team told us the exact location.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088#45

Please reply to the bug report and CC me.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Guido Günther]

Hi,
On Wed, Dec 06, 2017 at 08:48:17AM +0100, Markus Koschany wrote:
> On Fri, 1 Dec 2017 09:28:26 +0100 Guido =?iso-8859-1?Q?G=FCnther?=
>  wrote:
> [...]
> > I would rather not make psql connections from reportbug. http is
> > ubiquitous and can be proxied. That's why I mentioned the security
> > tracker. The nice thing about the security tracker is that we can change
> > what's stable, oldstable or lts without involving anybody else.
> 
> Hi Guido,
> 
> I have updated the patch according to your suggestions. It's a bit
> strange that we can't match release numbers and code name already. I
> think it would be best to implement this feature somewhere else but for
> the sake of moving forward the code will just fetch this json file now.
> At the moment I don't know the exact location at
> https://security-tracker.debian.org/ where I should put this
> information. Suggestions are welcome. Please find attached the debdiff
> against the latest version in unstable and the json file.

Looks good in principle. I would use a slightly different json format
though (using YAML for readability):

wheezy:
   major: 7
   alias: oldoldstable   
jessy:
   major: 8
   alias: oldstable
stretch:
   major: 9
   alias: stable 

This allows us to extend this in the future if necessary.
Cheers,
 -- Guido

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

On Wed, 6 Dec 2017 13:15:59 +0100 Raphael Geissert 
wrote:
> Hi,
> 
> On 6 Dec 2017 08:48, "Markus Koschany"  wrote:
> 
> I have updated the patch according to your suggestions. It's a bit
> strange that we can't match release numbers and code name already. I
> think it would be best to implement this feature somewhere else but for
> the sake of moving forward the code will just fetch this json file now.
> 
> 
> Isn't this provided already by the ftp-master API?
> Other than that there's also the madison interface to UDD. There might even
> be an API based on the new packages tracker, but I'm just guessing here.
> 

Hi,

thanks for pointing this out. Never heard of it before. I had a look at
the ftp-master API but it seems there is currently no link between
release number and code name and no way to tell whether a suite is
long-term supported.

https://api.ftp-master.debian.org/suite/wheezy

I guess I will contact the debian-dak list and request this feature. No
idea if the madison interface to UDD or tracker.debian.org provide more
information than that. For now I intend to use Guido's approach.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Raphael Geissert]

Hi,

On 6 Dec 2017 08:48, "Markus Koschany"  wrote:

I have updated the patch according to your suggestions. It's a bit
strange that we can't match release numbers and code name already. I
think it would be best to implement this feature somewhere else but for
the sake of moving forward the code will just fetch this json file now.


Isn't this provided already by the ftp-master API?
Other than that there's also the madison interface to UDD. There might even
be an API based on the new packages tracker, but I'm just guessing here.

Cheers,
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

On Fri, 1 Dec 2017 09:28:26 +0100 Guido =?iso-8859-1?Q?G=FCnther?=
 wrote:
[...]
> I would rather not make psql connections from reportbug. http is
> ubiquitous and can be proxied. That's why I mentioned the security
> tracker. The nice thing about the security tracker is that we can change
> what's stable, oldstable or lts without involving anybody else.

Hi Guido,

I have updated the patch according to your suggestions. It's a bit
strange that we can't match release numbers and code name already. I
think it would be best to implement this feature somewhere else but for
the sake of moving forward the code will just fetch this json file now.
At the moment I don't know the exact location at
https://security-tracker.debian.org/ where I should put this
information. Suggestions are welcome. Please find attached the debdiff
against the latest version in unstable and the json file.

Regards,

Markus
diff -Nru reportbug-7.1.7/bin/reportbug reportbug-7.1.7/bin/reportbug
--- reportbug-7.1.7/bin/reportbug   2017-05-29 22:00:17.0 +0200
+++ reportbug-7.1.7/bin/reportbug   2017-05-29 22:00:17.0 +0200
@@ -32,6 +32,8 @@
 import optparse
 import re
 import locale
+import requests
+import json
 import subprocess
 import shlex
 import email
@@ -1926,6 +1928,33 @@
 listcc += ui.get_multiline(
 'Enter any additional addresses this report should be sent to; 
press ENTER after each address.')
 
+# If the bug is reported against a package with a version that
+# indicates a security update add the security or lts team to CC
+# after user confirmation
+is_security_update = False
+if pkgversion:
+regex = re.compile('(\+|~)deb(\d+)u(\d+)')
+secversion = regex.search(pkgversion)
+if secversion:
+if ui.yes_no('Do you want to report a regression because of a 
security update? ',
+ 'Yes, please inform the LTS and security teams.',
+ 'No or I am not sure.', True):
+is_security_update = True
+distnumber = secversion[2]
+r = 
requests.get('https://security-tracker.debian.org/distribution.json')
+data = r.json()
+distribution = None
+for key, value in data.items():
+if distnumber in key:
+distribution = value
+
+if is_security_update and distribution is not None:
+if distribution == 'lts':
+email_address = ['debian-...@lists.debian.org']
+else:
+email_address = ['t...@security.debian.org']
+listcc.extend(email_address)
+
 if severity and rtype:
 severity = debbugs.convert_severity(severity, rtype)


distribution.json
Description: application/json


signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Guido Günther]

Hi Markus,
On Thu, Nov 30, 2017 at 06:38:27PM +0100, Markus Koschany wrote:
> On Wed, 29 Nov 2017 22:49:55 +0100 Guido =?iso-8859-1?Q?G=FCnther?=
>  wrote:
> [...]
> > Can't we deduce if it's LTS from either the packages version number or from
> > /etc/debian_version. Once we have the code name or number we could do a
> > simple HTTP call to check if this is stable, oldstable or lts.
> > 
> > I don't know of a page that exposes this information in JSON or similar
> > but if we don't have it we could add another page to the security
> > tracker like:
> > 
> > GET /tracker/data/releases
> > 
> > { 'stretch': 'stable',
> >   'jessie':  'oldstable',
> >   'wheezy':  'lts'
> > }
> > 
> > We then wouldn't be dependent on the string parsing in the changelog.
> 
> Hi Guido,
> 
> yes, in general that should be possible. Parsing /etc/debian_version
> might be dangerous though because it is well possible that someone
> reports a Wheezy bug from a development system running Sid or his
> workstation running stable. This might lead to wrong information.
> 
> Don't we already have the UDD database which tracks all package
> information in a convenient manner? It should be possible to lookup the
> version number and query the corresponding distribution/release code
> name. Looking at [1] I can find at least a releases table. If we create
> another table like your JSON idea it should be possible to match code
> name and suite. I don't know if this information is already present in
> UDD or if we have to create it first. We would need to import psycopg2
> for database connections and thus a dependency on python3-psycopg2.
> 
> Perhaps it might even more sense to add this feature to
> python3-debianbts, which is already a dependency of python3-reportbug,
> or more precisely the BTS itself. Perhaps it's already there and I just
> don't know it.

I would rather not make psql connections from reportbug. http is
ubiquitous and can be proxied. That's why I mentioned the security
tracker. The nice thing about the security tracker is that we can change
what's stable, oldstable or lts without involving anybody else.

Cheers,
 -- Guidox

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

On Wed, 29 Nov 2017 22:49:55 +0100 Guido =?iso-8859-1?Q?G=FCnther?=
 wrote:
[...]
> Can't we deduce if it's LTS from either the packages version number or from
> /etc/debian_version. Once we have the code name or number we could do a
> simple HTTP call to check if this is stable, oldstable or lts.
> 
> I don't know of a page that exposes this information in JSON or similar
> but if we don't have it we could add another page to the security
> tracker like:
> 
> GET /tracker/data/releases
> 
> { 'stretch': 'stable',
>   'jessie':  'oldstable',
>   'wheezy':  'lts'
> }
> 
> We then wouldn't be dependent on the string parsing in the changelog.

Hi Guido,

yes, in general that should be possible. Parsing /etc/debian_version
might be dangerous though because it is well possible that someone
reports a Wheezy bug from a development system running Sid or his
workstation running stable. This might lead to wrong information.

Don't we already have the UDD database which tracks all package
information in a convenient manner? It should be possible to lookup the
version number and query the corresponding distribution/release code
name. Looking at [1] I can find at least a releases table. If we create
another table like your JSON idea it should be possible to match code
name and suite. I don't know if this information is already present in
UDD or if we have to create it first. We would need to import psycopg2
for database connections and thus a dependency on python3-psycopg2.

Perhaps it might even more sense to add this feature to
python3-debianbts, which is already a dependency of python3-reportbug,
or more precisely the BTS itself. Perhaps it's already there and I just
don't know it.

Cheers,

Markus

[1] https://udd.debian.org/schema/udd.html



signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Guido Günther]

Hi Markus,
Great this is still moving forward!

On Wed, Nov 29, 2017 at 08:00:12PM +0100, Markus Koschany wrote:
> Hi!
[..snip..]
> I would prefer this solution. At the moment we check for the version
> string and I think that's sufficient for an initial check. The following
> actions should be triggered by the user himself by answering specific
> questions. What do you think about adding a second question after "Do
> you want to report a regression because of a security update?"
> 
> Is this regression in Debian's LTS release?
> 
> Yes, this bug is in the LTS release. -> only CC the LTS team
> No, this bug is not in the LTS release -> CC the security team

Can't we deduce if it's LTS from either the packages version number or from
/etc/debian_version. Once we have the code name or number we could do a
simple HTTP call to check if this is stable, oldstable or lts.

I don't know of a page that exposes this information in JSON or similar
but if we don't have it we could add another page to the security
tracker like:

GET /tracker/data/releases

{ 'stretch': 'stable',
  'jessie':  'oldstable',
  'wheezy':  'lts'
}

We then wouldn't be dependent on the string parsing in the changelog.

Cheers,
 -- Guido

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Hi!

On Wed, 29 Nov 2017 00:09:28 +0100 Raphael Geissert
 wrote:
> Hi,
> 
> On 9 October 2017 at 19:47, Markus Koschany  wrote:
> [...]
> > If the bug is reported against a package with a version number that
> > indicates a security update like +deb7u1 or ~deb8u3, both team mailing
> > lists should be added to CC after the bug reporter confirms that this
> > is a regression caused by a security update.
> 
> Perhaps reportbug could check the package's changelog to determine
> whether the latest update was a security or LTS one. It could do so by
> looking for the sec team's or LTS' snippet on the latest version.
> 
> Then and only then it could also ask for confirmation, as in: "is the
> bug a recent regression?", and CC the corresponding team. For
> instance, there's no need to CC the security team for regressions by
> LTS updates.

Adding both teams to CC was intentional because a regression might
affect more than one Debian distribution at the same time and sometimes
people just detect it in stable/oldstable/oldoldstable first but the
same bug affects the rest as well. Of course if we communicate such
regressions between both teams, we can change this behavior.

I don't see any mechanism or code in reportbug that deals with parsing
the changelog at the moment which means this idea is rather intrusive.
If we really want to go this route then we have to make sure that those
changelog strings are unambiguous like "Non-maintainer upload by the
security team" or "Non-maintainer upload by the LTS team". External
contributors which are not part of both teams also have to adhere to
this naming scheme.

I would prefer this solution. At the moment we check for the version
string and I think that's sufficient for an initial check. The following
actions should be triggered by the user himself by answering specific
questions. What do you think about adding a second question after "Do
you want to report a regression because of a security update?"

Is this regression in Debian's LTS release?

Yes, this bug is in the LTS release. -> only CC the LTS team
No, this bug is not in the LTS release -> CC the security team

What do you think about that? Please also ask the other team members for
their opinion.

Cheers,

Markus




signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Raphael Geissert]

Hi,

On 9 October 2017 at 19:47, Markus Koschany  wrote:
[...]
> If the bug is reported against a package with a version number that
> indicates a security update like +deb7u1 or ~deb8u3, both team mailing
> lists should be added to CC after the bug reporter confirms that this
> is a regression caused by a security update.

Perhaps reportbug could check the package's changelog to determine
whether the latest update was a security or LTS one. It could do so by
looking for the sec team's or LTS' snippet on the latest version.

Then and only then it could also ask for confirmation, as in: "is the
bug a recent regression?", and CC the corresponding team. For
instance, there's no need to CC the security team for regressions by
LTS updates.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Hello,

I still haven't got a response for Debian bug #878088 and I wonder if we
should implement this feature in Wheezy (and Jessie/Stretch if the
security team agrees) now. Are there any objections, hints, recommendations?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Hi,

is there anything that we can do to help getting this into unstable?
Would it be ok to patch the reportbug versions in Wheezy, Jessie and
Stretch to use this feature?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint

[Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Package: reportbug
Version: 7.1.7
Severity: wishlist
Tags: patch


Hi,

the Debian LTS Team and the Debian Security Team would like to propose
a new feature for reportbug.

We discussed this at DebConf 17 during the LTS BoF and shortly on
debian-lts [1] that it would make sense to inform both teams about
regressions introduced by security updates. We usually receive
word from the maintainer or users who report issues directly to
our mailing lists or IRC channels.

However we have also discovered that some regressions were never
reported to us. Hence we propose the following feature for reportbug:

If the bug is reported against a package with a version number that
indicates a security update like +deb7u1 or ~deb8u3, both team mailing
lists should be added to CC after the bug reporter confirms that this
is a regression caused by a security update. The confirmation check is
necessary to prevent too many false positives since similar version
strings are used for regular stable updates. However the default is true
because it is better to receive one e-mail too many as to miss the
regression. Of course this could be changed if it turns out that we
receive too many unwarranted reports.

Please find attached my proposed patch.

Regards,

Markus

[1] https://lists.debian.org/debian-lts/2017/08/msg00034.html
diff -Nru reportbug-7.1.7/bin/reportbug reportbug-7.1.7+nmu1/bin/reportbug
--- reportbug-7.1.7/bin/reportbug   2017-05-29 22:00:17.0 +0200
+++ reportbug-7.1.7+nmu1/bin/reportbug  2017-10-09 01:26:16.0 +0200
@@ -1926,6 +1926,22 @@
 listcc += ui.get_multiline(
 'Enter any additional addresses this report should be sent to; 
press ENTER after each address.')
 
+# If the bug is reported against a package with a version that
+# indicates a security update add the security and lts teams to CC
+# after user confirmation
+is_security_update = False
+if pkgversion:
+regex = re.compile('(\+|~)deb\d+u\d+')
+if regex.search(pkgversion):
+if ui.yes_no('Do you want to report a regression because of a 
security update? ',
+ 'Yes, please inform the LTS and security teams.',
+ 'No or I am not sure.', True):
+is_security_update = True
+
+if is_security_update:
+email_address = 
['debian-...@lists.debian.org','t...@security.debian.org']
+listcc.extend(email_address)
+
 if severity and rtype:
 severity = debbugs.convert_severity(severity, rtype)
 
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint