Bug#660190: security-tracker: add per-maintainer page (with half-baked patch)
On Mon, Mar 12, 2012 at 10:06 PM, Paul Wise wrote:
> On Mon, 2012-03-12 at 21:16 -0400, Michael Gilbert wrote:
>
>> Also, why is "c.execute("PRAGMA foreign_keys=ON")" necessary?
>
> sqlite doesn't enforce foreign key constraints by default:
>
> https://sqlite.org/foreignkeys.html#fk_enable
>
> I'm using those to ensure maintainers are deleted when source packages
> are deleted from the database.
There is a removed_packages table that you can use to check whether
the package is currently in debian or not.
>> At a cursory glance, this seems more complicated that it needs to be.
>> You're creating an "id" for each source package, but that is redundant
>> since the package name itself is a unique id.
>>
>> All you should need is a table with only sourcepkg names and
>> maintainer fields. Then when you process a view on (for example) a
>> maintainer page you can step through all sourcepkg names listed as
>> associated with that maintainer via that table.
>
> The source package name is definitely not unique since there are
> multiple suites that could have a line in the source package table.
It's still the same source package. You could step through each suite
separately on the maintainer pages since yes they will each have
different sets of issues.
> I'm not sure if the foreign key stuff would work with non-numeric keys.
Foreign keys should not be necessary at all.
> If a package gets removed from sid, we still want the issues present in
> stable to be listed on the maintainer's page. Going with your suggestion
> would mean that we would not know which maintainers to remove when a
> package is deleted from one particular suite.
You could limit results by checking that the release is in a supported
release (squeeze,wheezy,sid). All packages are considered in the
archive until they're not in any release.
But I really think you want a listing of issues per suite per maintainer.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANTw=mo2op1158+czfxhxtt+t389a8pc4qscen3iy-bkeap...@mail.gmail.com
Bug#663236: marked as done (security-tracker: DSA-2429-1 vs. tracker)
Your message dated Mon, 12 Mar 2012 22:40:12 -0400 with message-id and subject line Re: Bug#663236: security-tracker: DSA-2429-1 vs. tracker has caused the Debian Bug report #663236, regarding security-tracker: DSA-2429-1 vs. tracker to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 663236: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663236 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: security-tracker Severity: normal Hello everybody! DSA-2429-1 [1] says that a good number of vulnerabilities are fixed in sid by mysql-5.1/5.1.61-2 However, the tracker seems to disagree on one of them (CVE-2012-0119 [2]). Who's right and who's wrong? Please clarify and/or update the tracker data. Thanks for your time! [1] http://lists.debian.org/debian-security-announce/2012/msg00056.html [2] http://security-tracker.debian.org/tracker/CVE-2012-0119 --- End Message --- --- Begin Message --- > DSA-2429-1 [1] says that a good number of vulnerabilities are fixed > in sid by mysql-5.1/5.1.61-2 > However, the tracker seems to disagree on one of them > (CVE-2012-0119 [2]). > > Who's right and who's wrong? > Please clarify and/or update the tracker data. tracker issue. fixed now. thanks, mike --- End Message ---
Bug#660190: security-tracker: add per-maintainer page (with half-baked patch)
On Mon, 2012-03-12 at 21:16 -0400, Michael Gilbert wrote:
> Also, why is "c.execute("PRAGMA foreign_keys=ON")" necessary?
sqlite doesn't enforce foreign key constraints by default:
https://sqlite.org/foreignkeys.html#fk_enable
I'm using those to ensure maintainers are deleted when source packages
are deleted from the database.
> At a cursory glance, this seems more complicated that it needs to be.
> You're creating an "id" for each source package, but that is redundant
> since the package name itself is a unique id.
>
> All you should need is a table with only sourcepkg names and
> maintainer fields. Then when you process a view on (for example) a
> maintainer page you can step through all sourcepkg names listed as
> associated with that maintainer via that table.
The source package name is definitely not unique since there are
multiple suites that could have a line in the source package table.
I'm not sure if the foreign key stuff would work with non-numeric keys.
If a package gets removed from sid, we still want the issues present in
stable to be listed on the maintainer's page. Going with your suggestion
would mean that we would not know which maintainers to remove when a
package is deleted from one particular suite.
> There is also a debugging print statement.
>
Removed in my local checkout.
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#660190: security-tracker: add per-maintainer page (with half-baked patch)
On Sun, Mar 11, 2012 at 10:02 PM, Paul Wise wrote:
> On Fri, 2012-02-17 at 17:36 +0800, Paul Wise wrote:
>
>> The attached patch implements a first pass at a per-maintainer page of
>> security issues. It involves some database schema changes to it will
>> require a full reimport of all the data.
>
> Does anyone have some time to review my patch?
At a cursory glance, this seems more complicated that it needs to be.
You're creating an "id" for each source package, but that is redundant
since the package name itself is a unique id.
All you should need is a table with only sourcepkg names and
maintainer fields. Then when you process a view on (for example) a
maintainer page you can step through all sourcepkg names listed as
associated with that maintainer via that table.
Also, why is "c.execute("PRAGMA foreign_keys=ON")" necessary?
There is also a debugging print statement.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANTw=mps8apfdopqyxojn7fksxqdljqwff+fjhhk4jzjqr1...@mail.gmail.com
