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:
- [email protected] 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:
[email protected]
- debian-security@do seems to be redirected to debian-private@ldo
+ [email protected] seems to be redirected to
[email protected]
[email protected]
- [email protected]
+ [email protected]
(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 [email protected] 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 [email protected] and actually add the tag address as bcc
and then prevent sendmail from sending a copy to [email protected]
+ * N.b. that address should NOT be made public. E.g. for DEHS I used to
set the To: to [email protected] and actually add the tag address
as bcc and then prevent sendmail from sending a copy to
[email protected]
* 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 w
ay 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 [email protected]).
+ * 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 [email protected]).
* 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 @@
----------------------
- [email protected]
-- debian-security@do seems to be redirected to debian-private@ldo
+- [email protected] seems to be redirected to
[email protected]
- [email protected]
- [email protected]
- (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
_______________________________________________
Secure-testing-commits mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/secure-testing-commits
