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

[Markus Koschany]

>> This will not catch 404 or similar http status codes. If you don't care
>> about the type of error you can just do …
>>
>>r.raise_for_status()

Ok, got it. So adding r.raise_for_status() below the request line should
be sufficient because requests.exceptions.RequestException would also
catch this.

Thanks



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: Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

[sorry forgot to CC the rest]

Hello,

Am 29.01.2018 um 09:30 schrieb Guido Günther:
> Hi Markus,
> thanks for pursuing this! Some minor nitpicks:
>
> On Mon, Jan 29, 2018 at 12:11:03AM +0100, Markus Koschany wrote:
> [..snip..]
>> +if utils.is_security_update(package, 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):
>> +regex = re.compile('(\+|~)deb(\d+)u(\d+)')
>> +secversion = regex.search(pkgversion)
>> +distnumber = secversion.group(2)
>> +support = 'none'
>
> Using
>
>support = None
>
> is a bit more pythonic.

support = None was part of the very first iterations of this patch but
the string 'none' is used in distributions.json nowadays. I initialize
the variable with the same value and then I compare the value in our
support key. None is not equal to 'none' and caused an error when
Salvatore changed this value in distributions.json.

>> +email_address = []
>> +try:
>> +r =
requests.get('https://security-tracker.debian.org/tracker/distributions.json',
>> +timeout=self.options.timeout)
>
> This will not catch 404 or similar http status codes. If you don't care
> about the type of error you can just do …
>
>r.raise_for_status()
>
> … ff you dont handle the error this …
>
>> +data = r.json()
>
> … will fail like:
>
[...]
>
> … The raise_for_status exception is caught here alreadyx since
> requests.exceptions.HTTPError is a subclass of
> requests.exceptions.RequestException):
[...]

I thought requests.exceptions.RequestException is the exception base
class of Python requests and catches all cases? If not, would

except (requests.exceptions.RequestException,
requests.exceptions.HTTPError):

suffice?

> It would also improve readability if this whole code block moved into
a get_security_contact()
> function.

Maybe.

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: Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Am 28.01.2018 um 01:01 schrieb Nis Martensen:
> On 26-01-2018 15:45, Markus Koschany wrote:
>> I am not convinced that the apt-cache method is more efficient than
>> parsing the version string. I believe my method is simpler and it would
>> catch the same potential candidates as your apt-cache idea. Manual
>> intervention (answering a question) cannot be avoided unless the
>> security team agrees to receive all bug reports against a version with a
>> security update. I am absolutely sure that is not desired.
> 
> I agree that the question should be asked when the package version is a
> security update.  What I am trying to achieve using the apt-cache method
> (on top of the version string method) is to avoid asking the question
> for "normal" package updates in stable.

Ok, I have merged your patch and mine. Let's use that as basis for the
discussion to move forward. I have briefly tested the result but will do
more testing soon.

I noticed that you had to import apt but reportbug does not depend on
python3-apt. After I had installed this package it worked. I also
believe you don't need to check for the upstream changelog.gz file, the
Debian changelog should be sufficient.

> Attached a new version of the is_security_update function. This could be
> further refined by fetching the changelog from the package tracker if
> the package version is not the installed one, but this is probably going
> too far...
> 
> No idea how many of the stable package updates are usually normal bug
> fix updates compared to the number of security updates. If updates are
> almost all security updates, then we should definitely not do such
> micro-optimization and go with your original approach.

I assume there are more normal updates that go via a stable/oldstable
point update. Sometimes security updates and normal updates are
combined. Checking for the CVE string in the changelog file is probably
the only way to be sure in this case. Of course we will never catch the
situation when someone wants to report a security update regression but
in the meantime the security update was superseded by a normal update. I
don't know how common that is but it is hopefully negligible.

>> I favor my current patch because of the reasons I mentioned before. I
>> can remove the sys.exit call? What else should be done?
> 
> "secversion[2]" should be "secversion.group(2)", right?  The former
> variant did not work for me in a quick test.

This works in unstable for me. secversion[2] is equivalent to
secversion.group(2). But I presume you tested that with an older Python
version hence it didn't work for you. Since we want to backport the
patch to older releases I have changed this to secversion.group(2) as I
have already done it in Wheezy.

> Using an else clause may be more pythonic than my previous suggestion of
> moving more stuff into the try block.

I have moved most of the code inside the try block now.


> Reportbug has an "ewrite()" function that you can use for the warning
> message.

Thanks. I am using this one now.

> Reportbug has a concept of user expertise levels.  Can the question be
> skipped in novice mode?

Should it be skipped? Even novice users could detect such regressions.
We expect from them to choose severity levels, so why not expect that
they can answer a simple yes/no question? Though to keep it as simple as
possible for them I now check for self.options.mode == 'novice' and skip
the question completely in this case.

> Should reportbug incorporate a default version of the json file to fall
> back to if the lookup fails? Reportbug is probably going to be updated
> more often than the online version of the json file. An internal version
> could also be updated regularly.

I believe it is the other way around. From my experience reportbug is
less frequently updated and it is much simpler for us (and faster) to
change a value in distributions.json. You would also volunteer to keep
this file updated forever. Especially when Jessie will become
oldoldstable we need an update as soon as possible, otherwise reports
would be sent to the wrong address. I surely wouldn't mind to keep those
information like "supported" and "email address" in reportbug which
meant we could drop the requests code but judging from the feedback so
far, everyone seems to prefer the current distributions.json approach.

Markus


diff -Nru reportbug-7.1.8/bin/reportbug reportbug-7.1.8+nmu1/bin/reportbug
--- reportbug-7.1.8/bin/reportbug   2017-12-29 05:25:43.0 +0100
+++ reportbug-7.1.8+nmu1/bin/reportbug  2018-01-23 20:43:14.0 +0100
@@ -32,6 +32,8 @@
 import optparse
 import re
 import locale
+import requests
+import json
 import subprocess
 import shlex
 import email
@@ -1926,6 +1928,37 @@
 listcc += ui.get_mu

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

[Markus Koschany]

Am 26.01.2018 um 05:43 schrieb Sandro Tosi:
[...}
> i like the idea of trying hard to avoid to ask questions to the users
> so maybe we can do something like
> 
> * check if that version is coming from the debian-security repo
> ** if so, copy the relevant security team
> ** if not, ask the user

I try to respond to all the ideas that were mentioned by Nis and you to
avoid the question to end users.

We have two different teams. The LTS team and the security team. The
security team is responsible for stable and oldstable security updates
while the LTS team takes care of oldoldstable. I see several issues with
the apt-cache approach.

If we check whether the update is coming from the debian-security repo,
then only the security team is concerned. All LTS updates are from
oldoldstable or from the distribution codename (at the moment this is
Wheezy).

If I implemented your suggestion then all bug reports for a
"Debian-Security" update would be automatically copied to the security
team's mailing list. As I have pointed out before, it is possible that
the user just wants to report a "normal" bug in a version with a
security update which is completely unrelated to a security update. The
same reasoning applies to the idea of checking for "oldoldstable". The
only way to avoid unwarranted copies is to ask the user directly. There
might still be false-positives but there should be far less noise in
comparison to

if Debian-Security:
  CC security team
else ask user


Replying to Nis' questions:

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

We have the UDD database that provides a plethora of information about
packages in all distributions.

https://wiki.debian.org/UltimateDebianDatabase/

A PostgreSQL database query is required though. We have already
discussed in this bug report that a https request is simpler and better.
We could also parse the changelog for strings like CVE-2018-. A
security update should always include the CVE identifier.

Again these would be alternative methods to determine whether a package
has received a security update. It does not solve the problem whether
the user wants to report a normal bug instead.

> Would it be feasible to make all security updates available via the
> security update channel?

No. Low priority updates are released via a stable/oldstable point
update. LTS updates are also handled differently via oldoldstable.

>  Then the simple suggested method would be
> sufficient.  But it is probably infeasible, otherwise it would be done?

If there was one channel for all security updates you would be correct.
But even then I don't see an advantage compared to parsing the version
string like I do. It is simpler and catches all relevant updates already.

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

I am not convinced that the apt-cache method is more efficient than
parsing the version string. I believe my method is simpler and it would
catch the same potential candidates as your apt-cache idea. Manual
intervention (answering a question) cannot be avoided unless the
security team agrees to receive all bug reports against a version with a
security update. I am absolutely sure that is not desired.

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

I favor my current patch because of the reasons I mentioned before. I
can remove the sys.exit call? What else should be done?

> in neither case is acceptable to sys.exit() if you cant connect to the
> internet: either you decide a default address for this case, or print
> a warning message that you cant fetch the needed information and the
> sec team wont be copied in the repo.

> thanks both for working together on reaching consensus

I can move the code in the try-block as suggested by Nis and simply drop
the sys.exit call. I am already printing a warning message. Is using
print sufficient in this case or is there a better method to visualize
the error? I can extend the message a bit and mention our mailing list
address.

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]

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

[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: Bug#878088: Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Please find attached the updated version of the patch.

Now the patch checks for --offline mode and skips the section if this is
true.

The --timeout flag is honored and passed to requests.

The listcc bug is fixed. It turned out that the email_address was a
string and not a list anymore. The extend function works but I changed
it to += like it is used in the rest of the code.

Please advise how an exception should be handled if
security-tracker.debian.org is not reachable. I clarified the error
message but the sys.exit(1) command is still used. Please let me know if
you have implemented some form of network exception handling already and
how it can be used, although I feel the error message is clear now.

Regards,

Markus

diff -Nru reportbug-7.1.8/bin/reportbug reportbug-7.1.8+nmu1/bin/reportbug
--- reportbug-7.1.8/bin/reportbug   2017-12-29 05:25:43.0 +0100
+++ reportbug-7.1.8+nmu1/bin/reportbug  2018-01-23 20:43:14.0 +0100
@@ -32,6 +32,8 @@
 import optparse
 import re
 import locale
+import requests
+import json
 import subprocess
 import shlex
 import email
@@ -1926,6 +1928,36 @@
 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 and not self.options.offline:
+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]
+try:
+r = 
requests.get('https://security-tracker.debian.org/tracker/distributions.json',
+timeout=self.options.timeout)
+except requests.exceptions.RequestException:
+print('Unable to connect to 
security-tracker.debian.org. Please try again later.')
+sys.exit(1)
+data = r.json()
+support = 'none'
+email_address = []
+for key, value in data.items():
+if distnumber == value['major-version']:
+support = value['support']
+email_address = value['contact']
+
+if is_security_update and support != 'none':
+listcc += [email_address]
+
 if severity and rtype:
 severity = debbugs.convert_severity(severity, rtype)
 
diff -Nru reportbug-7.1.8/debian/changelog reportbug-7.1.8+nmu1/debian/changelog
--- reportbug-7.1.8/debian/changelog2017-12-29 05:25:43.0 +0100
+++ reportbug-7.1.8+nmu1/debian/changelog   2018-01-23 20:43:14.0 
+0100
@@ -1,3 +1,10 @@
+reportbug (7.1.8+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * 
+
+ -- Markus Koschany <a...@debian.org>  Tue, 23 Jan 2018 20:43:14 +0100
+
 reportbug (7.1.8) unstable; urgency=medium
 
   * reportbug/debbugs.py


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: Bug#878088: Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Hello,

Am 24.01.2018 um 01:16 schrieb Sandro Tosi:
> sorry but did you even actually test your patch? this is the CC list:
> 
> X-Debbugs-Cc: mo...@debian.org, t, e, a, m, @, s, e, c, u, r, i, t, y,
> ., d, e, b, i, a, n, ., o, r, g
> 
> this wont work i guess; just use listcc += as in the rest of the code?

I did test my patches and I am using listcc already. Are you sure you
applied the latest debdiff against the version in unstable?
 >>> * did you test what happen in offline mode and fix the eventual
regression?
>>
>> I have tested reportbug with
>>
>> reportbug --offline 
> 
> the point is that in offline mode, it should *not* use any network
> (you know, like if you are offline) and thus default to not copy the
> security team and skip the entire branch, smth like "if pkgversion and
> not options.offline"

I do understand the meaning of the word "offline". If you prefer using

if pkgversion and not options.offline

I am totally fine with this construct. I am not familiar with your code.
That is why I am asking you for comments.

>>
>> and added a try/except block to catch any exceptions that may occur with
>> Python Requests (timeouts, network errors, etc.). If we reach this point
>> in our code without a network connection, the program will exit because
>> we need the information in distributions.json to proceed. Otherwise
>> everything else works as expected.
> 
> please support the --timeout cli option and fail gracefully if you
> cant contact security.d.o (sys.exit if you cant reach it is extremely
> rude to users!) by not copying the security team.

I only saw that you used sys.exit in different parts of your code
yourself. Please note that a timeout is just one possible exception for
Python Requests, so it has to be catched separately. I will look into
the --timeout cli option later.

[...]
> Did you check Nis suggestion at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088#199 to check
> apt-cache output (possibly via python3-apt) to see if that version is
> coming from the updates stream? since it's on the table and you didnt
> comment on it yet, i wanted to point it out.

Yes, I read Nis suggestion and also your reply to it. I am also of the
opinion that apt-cache is not a way to determine whether the user wants
to report a regression due to a security update. It is completely
possible that he just wants to report a normal bug in a version that
already received a security update. We cannot catch this situation if we
don't ask this question.

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: Bug#878088: Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Am 23.01.2018 um 05:19 schrieb Sandro Tosi:
>> What can we do to get this feature into reportbug?
> 
> * did you update the patch to include the new contact field in
> distribution.json and not hardcode the email address?

Done.

> * did you test what happen in offline mode and fix the eventual regression?

I have tested reportbug with

reportbug --offline 

and added a try/except block to catch any exceptions that may occur with
Python Requests (timeouts, network errors, etc.). If we reach this point
in our code without a network connection, the program will exit because
we need the information in distributions.json to proceed. Otherwise
everything else works as expected.

> i did a quick check on the number of bugs reported in a week, and over
> the 600+ bugs filed, less than 30 where for a stable release (either
> stretch or previous ones); i think you may also clarify that prompt,
> as i suspect users will get rather confused "how am i supposed to know
> if this is a security update? i just apt-get upgrade the system and
> now this package doesnt work" kind of scenario.

I don't know how I can clarify this prompt at the moment. I have added
it because the security team does not want to be informed of any bug
report against a package with a stable update or security update. The
description of the Y/N choice is quite clear. If you are not sure, press
N. Otherwise just hit the Enter key. Before we can evaluate the
usefulness of this prompt we need some data from experience.

Please find attached the updated version of the patch.

Regards,

Markus
diff -Nru reportbug-7.1.8/bin/reportbug reportbug-7.1.8+nmu1/bin/reportbug
--- reportbug-7.1.8/bin/reportbug   2017-12-29 05:25:43.0 +0100
+++ reportbug-7.1.8+nmu1/bin/reportbug  2018-01-23 20:43:14.0 +0100
@@ -32,6 +32,8 @@
 import optparse
 import re
 import locale
+import requests
+import json
 import subprocess
 import shlex
 import email
@@ -1926,6 +1928,34 @@
 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]
+try:
+r = 
requests.get('https://security-tracker.debian.org/tracker/distributions.json')
+except requests.exceptions.RequestException as e:
+print (e)
+sys.exit(1)
+data = r.json()
+support = 'none'
+for key, value in data.items():
+if distnumber == value['major-version']:
+support = value['support']
+email_address = value['contact']
+
+if is_security_update and support != 'none':
+listcc.extend(email_address)
+
 if severity and rtype:
 severity = debbugs.convert_severity(severity, rtype)
 
diff -Nru reportbug-7.1.8/debian/changelog reportbug-7.1.8+nmu1/debian/changelog
--- reportbug-7.1.8/debian/changelog2017-12-29 05:25:43.0 +0100
+++ reportbug-7.1.8+nmu1/debian/changelog   2018-01-23 20:43:14.0 
+0100
@@ -1,3 +1,10 @@
+reportbug (7.1.8+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * 
+
+ -- Markus Koschany <a...@debian.org>  Tue, 23 Jan 2018 20:43:14 +0100
+
 reportbug (7.1.8) unstable; urgency=medium
 
   * reportbug/debbugs.py


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: Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Control: tags -1 -pending

On Fri, 29 Dec 2017 16:12:49 +0100 Markus Koschany <a...@debian.org> wrote:
> Hello Sandro,
> 
> Am 29.12.2017 um 02:27 schrieb Sandro Tosi:
> > Hello everyone,
> > let me first apologize for the long time with no input from the
> > reportbug maints.

*ping*

What can we do to get this feature into reportbug?

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: Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Hello Sandro,

Am 29.12.2017 um 02:27 schrieb Sandro Tosi:
> Hello everyone,
> let me first apologize for the long time with no input from the
> reportbug maints.

Yes, we were eagerly interested in your comments for this feature but
had to move forward.

> i had a look a the patch and.. i'm not really happy :( it looks like
> the version format is the same for both security updates and stable
> updates: this means for every bug report (on a stable release against
> an updated package) the user will get a prompt if this is a regression
> due to a security update, and they may have no clue because all they
> did is dist-upgrading.

Unfortunately there is no way to differentiate between a security update
and a regular stable update. Stable updates can also include security
fixes which did not warrant a security announcement. The only way to
limit the amount of false notifications to both team mailing lists was
to create a prompt and to ask the user whether this is a security update
regression. If there is a better way to deal with this problem we should
do that.

> i'm not super-excited about making a synchronous call to
> distributions.json but let's say i can live with that (did you try
> your patch with the -O/--offline mode?)

No, I did not try the patch with the --offline flag because we assumed
internet access due to distributions.json.

> is there a way s-t.d.o can get
> queried at the same time to know if the current package/version comes
> from the secteam/lts or is coming from the pkg maintainer as a normal
> stable update?

I am not aware of a method to retrieve this information. Like I said
stable updates can also include security updates and the only way to
determine whether something is a stable/security update is to parse the
package version string. There is no differentiation at the moment.

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]

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: diff for NMU version 7.1.7+nmu2

[Markus Koschany]

I noticed that Laurent Bigonville already uploaded an NMU versioned as
7.1.7+nmu1 yesterday. I have rescheduled my NMU now and uploaded to
delayed/14 instead.

Regards,

Markus
diff -Nru reportbug-7.1.7+nmu1/bin/reportbug reportbug-7.1.7+nmu2/bin/reportbug
--- reportbug-7.1.7+nmu1/bin/reportbug	2017-12-16 12:16:37.0 +0100
+++ reportbug-7.1.7+nmu2/bin/reportbug	2017-12-17 18:53:39.0 +0100
@@ -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 == 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)
 
diff -Nru reportbug-7.1.7+nmu1/debian/changelog reportbug-7.1.7+nmu2/debian/changelog
--- reportbug-7.1.7+nmu1/debian/changelog	2017-12-16 14:40:50.0 +0100
+++ reportbug-7.1.7+nmu2/debian/changelog	2017-12-17 18:53:39.0 +0100
@@ -1,3 +1,11 @@
+reportbug (7.1.7+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * bin/reportbug: Inform lts and security team about potential regressions due
+to security updates. (Closes: #878088)
+
+ -- Markus Koschany <a...@debian.org>  Sun, 17 Dec 2017 18:53:39 +0100
+
 reportbug (7.1.7+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
Binärdateien /mnt/data/tmp/1KXJ6xe3mP/reportbug-7.1.7+nmu1/reportbug/__pycache__/__init__.cpython-36.pyc und /mnt/data/tmp/RFjQw0EMYC/reportbug-7.1.7+nmu2/reportbug/__pycache__/__init__.cpython-36.pyc sind verschieden.
___
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: diff for NMU version 7.1.7+nmu1

[Markus Koschany]

Control: tags 878088 + pending

Dear maintainer,

I've prepared an NMU for reportbug (versioned as 7.1.7+nmu1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards,

Markus
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-12-17 16:23:19.0 +0100
@@ -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 == 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)
 
diff -Nru reportbug-7.1.7/debian/changelog reportbug-7.1.7+nmu1/debian/changelog
--- reportbug-7.1.7/debian/changelog	2017-05-29 22:00:17.0 +0200
+++ reportbug-7.1.7+nmu1/debian/changelog	2017-12-17 16:23:19.0 +0100
@@ -1,3 +1,11 @@
+reportbug (7.1.7+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * bin/reportbug: Inform lts and security team about potential regressions due
+to security updates. (Closes: #878088)
+
+ -- Markus Koschany <a...@debian.org>  Sun, 17 Dec 2017 16:23:19 +0100
+
 reportbug (7.1.7) unstable; urgency=medium
 
   * reportbug/utils.py
Binärdateien /mnt/data/tmp/R1gJwpx6oc/reportbug-7.1.7/reportbug/__pycache__/__init__.cpython-36.pyc und /mnt/data/tmp/RS27AvS1HP/reportbug-7.1.7+nmu1/reportbug/__pycache__/__init__.cpython-36.pyc sind verschieden.
___
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

[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

[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

[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

[Markus Koschany]

On Wed, 6 Dec 2017 13:15:59 +0100 Raphael Geissert <geiss...@debian.org>
wrote:
> Hi,
> 
> On 6 Dec 2017 08:48, "Markus Koschany" <a...@debian.org> 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

[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

[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

[Markus Koschany]

Hi!

On Wed, 29 Nov 2017 00:09:28 +0100 Raphael Geissert
<geiss...@debian.org> wrote:
> Hi,
> 
> On 9 October 2017 at 19:47, Markus Koschany <a...@debian.org> 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

[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