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

1 files changed, 4 insertions, 4 deletions

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