[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: morph at 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 <package>
> 
> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/reportbug-maint/attachments/20180124/46bddbad/attachment.sig>