[Secure-testing-commits] r37970 - / doc doc/security-team.d.o org
Salvatore Bonaccorso
carnil at moszumanska.debian.org
Sun Nov 29 09:43:55 UTC 2015
Author: carnil
Date: 2015-11-29 09:43:55 +0000 (Sun, 29 Nov 2015)
New Revision: 37970
Modified:
TODO.gitmigration
doc/DC13-BoF.txt
doc/README.releases
doc/buildds
doc/secteamessen2014-latest.txt
doc/security-team.d.o/contact
org/TODO
Log:
Replacements in e-mail addresses and host names/URL's and punctuation fixes
Thanks: Sander Bos
Modified: TODO.gitmigration
===================================================================
--- TODO.gitmigration 2015-11-29 07:03:32 UTC (rev 37969)
+++ TODO.gitmigration 2015-11-29 09:43:55 UTC (rev 37970)
@@ -29,7 +29,7 @@
+ secure-testing-commits mailing list:
- sectracker at soriano.debian.org needs to be subscribed to the
commits list which are used as triggers to update / create
- sec-tracker information on security-tracker.d.o (soriano)
+ sec-tracker information on security-tracker.debian.org (soriano)
Todos:
======
Modified: doc/DC13-BoF.txt
===================================================================
--- doc/DC13-BoF.txt 2015-11-29 07:03:32 UTC (rev 37969)
+++ doc/DC13-BoF.txt 2015-11-29 09:43:55 UTC (rev 37970)
@@ -29,9 +29,9 @@
- Specify public/private ; internal/external
- What each list is for:
debian-security at lists.debian.org
- debian-security at do seems to be redirected to debian-private at ldo
+ debian-security at debian.org seems to be redirected to debian-private at lists.debian.org
debian-security-tracker at lists.debian.org
- team at security.d.o
+ team at security.debian.org
(and more)
- consolidate lists? (which are needed?; explicit names, e.g. -public/-private)
- RT? (incoming queue for non encrypted mails)
@@ -66,7 +66,7 @@
- Private queue in RT
- "Special" packages
- CVE ids pool: when to use, how to ask more ids
- - "Resolutions", "Announces"? like the Amazon CDN for security.d.o (bits from the security team)
+ - "Resolutions", "Announces"? like the Amazon CDN for security.debian.org (bits from the security team)
- Access to private key
- Access to upstream bug trackers
@@ -78,4 +78,4 @@
- some (hidden) documentation in repo
- section about security in developer's reference
- Securing Debian Manual (harden-doc) -> linked in the main page?
- - update it
\ No newline at end of file
+ - update it
Modified: doc/README.releases
===================================================================
--- doc/README.releases 2015-11-29 07:03:32 UTC (rev 37969)
+++ doc/README.releases 2015-11-29 09:43:55 UTC (rev 37970)
@@ -5,7 +5,7 @@
[ ] Update doc/DSA.template
[ ] Update bin/gen-DSA
-[ ] Update security-team.d.o pages
+[ ] Update security-team.debian.org pages
Security Tracker code
---------------------
Modified: doc/buildds
===================================================================
--- doc/buildds 2015-11-29 07:03:32 UTC (rev 37969)
+++ doc/buildds 2015-11-29 09:43:55 UTC (rev 37970)
@@ -29,6 +29,6 @@
mips tbm
m68k yoe
-it seems the above list is outdated since we moved to security.d.o.
+it seems the above list is outdated since we moved to security.debian.org.
A more current list is at
klecker:/org/security.debian.org/doc/buildd-admins.txt
Modified: doc/secteamessen2014-latest.txt
===================================================================
--- doc/secteamessen2014-latest.txt 2015-11-29 07:03:32 UTC (rev 37969)
+++ doc/secteamessen2014-latest.txt 2015-11-29 09:43:55 UTC (rev 37970)
@@ -19,7 +19,7 @@
* If mail is sent to PACKAGENAME at qa.debian.org also interested non-maintainers are notified
* A magic header is needed to get the mail through (see dev ref)
* Sending to a specific tag can be done with ${package}_${tag}@packages.qa.debian.org (e.g. tag=summary)
- * N.b. that address should NOT be made public. E.g. for DEHS I used to set the To: to $package at packages.qa.d.o and actually add the tag address as bcc and then prevent sendmail from sending a copy to $package at packages.qa.d.o
+ * N.b. that address should NOT be made public. E.g. for DEHS I used to set the To: to $package at packages.qa.debian.org and actually add the tag address as bcc and then prevent sendmail from sending a copy to $package at packages.qa.debian.org
* Check open bugs in the BTS, check bugs against security-tracker pseudo package (bugs.debian.org/security-tracker)
* Tracker needs some changes first, check at a later point. Most of the issues are no longer relevant anyway probably
@@ -77,7 +77,7 @@
* Deprecate RT:
* Setup a private repository for embargoed issues
* Do a spring cleaning of remaining issues and add them to dsa-needed, close the tickets or add them to the private repository
- * Close rt.debian.org security queues and update information recommending maintainers to open a ticket if they want to report a security issues (wiki.d.o page and dev-ref)
+ * Close rt.debian.org security queues and update information recommending maintainers to open a ticket if they want to report a security issues (wiki.debian.org page and dev-ref)
* Maintain a file in SVN to track TODO items which are not related to preparing security updates, e.g. work on infrastructure
* org/TODO
@@ -93,7 +93,7 @@
* ok we disagree here then, but that's fine. in my personal opinion that just belongs to what i consider a professional security advisory and i don't like hinting/relying to/on further external sources that we might know, but the end user not or simply doesn't care about. the term sucks, it should be access vector or something. but i do think it provides people processing DSAs another criteria that allows people to quickly determine whether they care or notthat allows people to quickly determine whether they care or not what i mean wrt debian-specific bugs is not if an administrator cares if its debian specific or not. i agree, it doesnt matter. what i meant is that in the case the origin of an issue is debian, external sites use our advisories as the source/reference, so i think they should be complete in this aspect rather than making something up or guessing. im all for reducing the amount of work that goes into advisories, but im not for stripping it to a level where its way sub-par of "industry standards". and cvss is not an argument at all in my book, this is completely ignored by a large fraction of people due to its questionable use
* Reference the CVEs to the security-tracker instead of the cve.mitre.org page (on the generated webpages -- section Security database references).
* Incude link to the webpage and tracker in the mail? nope
- * So, "Vulnerability" hasn't been dropped yet, as some of this information is also used to generate the webpages below security.d.o. The release team also uses it to generate the announcements
+ * So, "Vulnerability" hasn't been dropped yet, as some of this information is also used to generate the webpages below security.debian.org. The release team also uses it to generate the announcements
* Crossreferences to cvs.mitre.org change to the security-tracker pages should be enough.
* Review developers reference, does it still reflect current best practices?
@@ -182,7 +182,7 @@
* Create a one-stop web page security-team.debian.org which links all information wrt to working/contrbuting on security, e.g. links to the tracker, introduction information, links to useful wiki pages etc. release.debian.org is a good example for such a specific target page.This information shouldn't be collected on www.debian.org/security since this is targeted for people using security updates
* Remove mentions of the "testing security team" since that doesn't seem to exist anymore?
- * remove/rename all secure-testing mailing list and repositories? (need to collect information where they are all used, e.g. reportbug send's a email to also secure-testing-team address when tag security is set -- and fortunately also to team at security.d.o).
+ * remove/rename all secure-testing mailing list and repositories? (need to collect information where they are all used, e.g. reportbug send's a email to also secure-testing-team address when tag security is set -- and fortunately also to team at security.debian.org).
* Alioth project is still called secure-testing, ask Alioth admins whether a rename of the Alioth project is possible. Once renamed, simply fix up the fallout of the rename. If possible rename it to security-tracker.
* Check out the documentation index for a kinda of TODO of the future sections: https://alioth.debian.org/scm/viewvc.php/doc/public/index?view=markup&root=secure-testing
Modified: doc/security-team.d.o/contact
===================================================================
--- doc/security-team.d.o/contact 2015-11-29 07:03:32 UTC (rev 37969)
+++ doc/security-team.d.o/contact 2015-11-29 09:43:55 UTC (rev 37970)
@@ -7,7 +7,7 @@
----------------------
- debian-security at lists.debian.org
-- debian-security at do seems to be redirected to debian-private at ldo
+- debian-security at debian.org seems to be redirected to debian-private at lists.debian.org
- debian-security-tracker at lists.debian.org
- team at security.debian.org
- (and more)
@@ -21,4 +21,4 @@
(http://www.oftc.net/), stop by if you'd like. We can also add you to
the Alioth project so you have SVN write permission, and you can test
drive it on the testing issues for however long you like to get an idea
-or feel comfortable (and hey, it really helps!)
+or feel comfortable (and hey, it really helps!).
Modified: org/TODO
===================================================================
--- org/TODO 2015-11-29 07:03:32 UTC (rev 37969)
+++ org/TODO 2015-11-29 09:43:55 UTC (rev 37970)
@@ -47,7 +47,7 @@
somewhere/in the git repository.
- the sectracker user is subscribed to the commits mailinglists, and
the commit messages trigger updates of the tracker.
- - http://security-team.debian.org (on dillon.d.o) is updated from svn,
+ - http://security-team.debian.org (on dillon.debian.org) is updated from svn,
needs to be switched (simple)
- https://contributors.debian.org/source/Debian%20Security%20Tracker
- Allocating DSA's + DLA's: svn guarantees we do not race on DSA+DLA
@@ -65,7 +65,7 @@
information
- check if the developers-reference (https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security)
still holds updated information.
- - check if the security related information in wiki.d.o is updated. (luciano)
+ - check if the security related information in wiki.debian.org is updated. (luciano)
- Teams/TestingSecurity (tagged as deprecated)
- http://testing-security.debian.net/
- https://www.debian.org/doc/manuals/securing-debian-howto/ch10.en.html#s-security-support-testing
More information about the Secure-testing-commits
mailing list