Replacements in e-mail addresses and host names/URL's and punctuation fixes

Thanks: Sander Bos

git-svn-id: svn+ssh://svn.debian.org/svn/secure-testing@37970 e39458fd-73e7-0310-bf30-c45bca0a0e42

7 files changed, 15 insertions, 15 deletions

diff --git a/TODO.gitmigration b/TODO.gitmigration
index 151cddf16c..4f17445176 100644
--- a/TODO.gitmigration
+++ b/TODO.gitmigration
@@ -29,7 +29,7 @@ Repository on alioth
   + secure-testing-commits mailing list:
     - sectracker@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:
 ======
diff --git a/doc/DC13-BoF.txt b/doc/DC13-BoF.txt
index f67563dbea..5bc7f219bc 100644
--- a/doc/DC13-BoF.txt
+++ b/doc/DC13-BoF.txt
@@ -29,9 +29,9 @@ Organization
    - Specify public/private ; internal/external
    - What each list is for:
      debian-security@lists.debian.org
-     debian-security@do seems to be redirected to debian-private@ldo
+     debian-security@debian.org seems to be redirected to debian-private@lists.debian.org
      debian-security-tracker@lists.debian.org
-     team@security.d.o
+     team@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 @@ Internal (?) processes
  - 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 @@ What do we have
 - 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
diff --git a/doc/README.releases b/doc/README.releases
index 25b3d4c026..c24e68006f 100644
--- a/doc/README.releases
+++ b/doc/README.releases
@@ -5,7 +5,7 @@ General
 
 [ ] Update doc/DSA.template
 [ ] Update bin/gen-DSA
-[ ] Update security-team.d.o pages
+[ ] Update security-team.debian.org pages
 
 Security Tracker code
 ---------------------
diff --git a/doc/buildds b/doc/buildds
index 5ee2910d08..de65021c97 100644
--- a/doc/buildds
+++ b/doc/buildds
@@ -29,6 +29,6 @@ hppa    zobel
 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
diff --git a/doc/secteamessen2014-latest.txt b/doc/secteamessen2014-latest.txt
index 47abc07d77..1bdb95a85a 100644
--- a/doc/secteamessen2014-latest.txt
+++ b/doc/secteamessen2014-latest.txt
@@ -19,7 +19,7 @@ Tracker
      * If mail is sent to PACKAGENAME@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@packages.qa.d.o and actually add the tag address as bcc and then prevent sendmail from sending a copy to $package@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@packages.qa.debian.org and actually add the tag address as bcc and then prevent sendmail from sending a copy to $package@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 @@ Workflow
  * 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 @@ Workflow
      * 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 @@ Documentation
  * 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@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@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
diff --git a/doc/security-team.d.o/contact b/doc/security-team.d.o/contact
index 6b2b34e71f..4da61ec929 100644
--- a/doc/security-team.d.o/contact
+++ b/doc/security-team.d.o/contact
@@ -7,7 +7,7 @@ What each list is for:
 ----------------------
 
 - debian-security@lists.debian.org
-- debian-security@do seems to be redirected to debian-private@ldo
+- debian-security@debian.org seems to be redirected to debian-private@lists.debian.org
 - debian-security-tracker@lists.debian.org
 - team@security.debian.org
 - (and more)
@@ -21,4 +21,4 @@ We hang-out in the #debian-security channel on OFTC
 (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!).
diff --git a/org/TODO b/org/TODO
index 83db67a4a3..ecf8265693 100644
--- a/org/TODO
+++ b/org/TODO
@@ -47,7 +47,7 @@ Security Tracker svn to git conversion
    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 @@ Web pages
    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