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-1111. 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
