===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/errata25.html,v
retrieving revision 1.70
retrieving revision 1.71
diff -c -r1.70 -r1.71
*** www/errata25.html	2016/08/15 02:22:06	1.70
--- www/errata25.html	2016/10/16 19:11:29	1.71
***************
*** 70,76 ****
  <br>
  <hr>
  
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5.tar.gz">
  You can also fetch a tar.gz file containing all the following patches</a>.
  This file is updated once a day.
  <p>
--- 70,76 ----
  <br>
  <hr>
  
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5.tar.gz">
  You can also fetch a tar.gz file containing all the following patches</a>.
  This file is updated once a day.
  <p>
***************
*** 91,97 ****
  &nbsp; <i>All architectures</i><br>
  In cron(8), make sure argv[] is NULL terminated in the fake popen() and
  run sendmail as the user, not as root.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/012_cron.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="miscfs">
--- 91,97 ----
  &nbsp; <i>All architectures</i><br>
  In cron(8), make sure argv[] is NULL terminated in the fake popen() and
  run sendmail as the user, not as root.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/012_cron.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="miscfs">
***************
*** 100,113 ****
  The procfs and fdescfs filesystems had an overrun in their handling
  of uio_offset in their readdir() routines. (These filesystems are not
  enabled by default).
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/011_miscfs.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="profil">
  <font color="#009000"><strong>SECURITY FIX: Aug 9, 1999</strong></font>
  &nbsp; <i>All architectures</i><br>
  Stop profiling (see profil(2)) when we execve() a new process.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/010_profil.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="ipsec_in_use">
--- 100,113 ----
  The procfs and fdescfs filesystems had an overrun in their handling
  of uio_offset in their readdir() routines. (These filesystems are not
  enabled by default).
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/011_miscfs.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="profil">
  <font color="#009000"><strong>SECURITY FIX: Aug 9, 1999</strong></font>
  &nbsp; <i>All architectures</i><br>
  Stop profiling (see profil(2)) when we execve() a new process.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/010_profil.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="ipsec_in_use">
***************
*** 115,121 ****
  &nbsp; <i>All architectures</i><br>
  Packets that should have been handled by IPsec may be transmitted
  as cleartext. PF_KEY SA expirations may leak kernel resources.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/009_ipsec_in_use.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="rc">
--- 115,121 ----
  &nbsp; <i>All architectures</i><br>
  Packets that should have been handled by IPsec may be transmitted
  as cleartext. PF_KEY SA expirations may leak kernel resources.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/009_ipsec_in_use.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="rc">
***************
*** 123,129 ****
  &nbsp; <i>All architectures</i><br>
  In /etc/rc, use mktemp(1) for motd re-writing, and change the find(1)
  to use -execdir.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/008_rc.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="chflags">
--- 123,129 ----
  &nbsp; <i>All architectures</i><br>
  In /etc/rc, use mktemp(1) for motd re-writing, and change the find(1)
  to use -execdir.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/008_rc.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="chflags">
***************
*** 131,137 ****
  &nbsp; <i>All architectures</i><br>
  Do not permit regular users to chflags(2) or fchflags(2) on character or
  block devices which they may currently be the owner of.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/007_chflags.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="nroff">
--- 131,137 ----
  &nbsp; <i>All architectures</i><br>
  Do not permit regular users to chflags(2) or fchflags(2) on character or
  block devices which they may currently be the owner of.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/007_chflags.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="nroff">
***************
*** 141,147 ****
  to avoid various groff features which may be security issues.  On the
  whole, this is not really a security issue, but it was discussed on
  BUGTRAQ as if it is.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/006_nroff.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="fts">
--- 141,147 ----
  to avoid various groff features which may be security issues.  On the
  whole, this is not really a security issue, but it was discussed on
  BUGTRAQ as if it is.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/006_nroff.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="fts">
***************
*** 149,155 ****
  &nbsp; <i>All architectures</i><br>
  Programs using fts(3) could dump core when given a directory structure
  with a very large number of entries.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/005_fts.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="tcpsack">
--- 149,155 ----
  &nbsp; <i>All architectures</i><br>
  Programs using fts(3) could dump core when given a directory structure
  with a very large number of entries.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/005_fts.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="tcpsack">
***************
*** 157,163 ****
  &nbsp; <i>All architectures</i><br>
  Sequence numbers could wrap with TCP_SACK and TCP_NEWRENO, resulting in
  failure to retransmit correctly.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/004_tcpsack.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="ipsec1">
--- 157,163 ----
  &nbsp; <i>All architectures</i><br>
  Sequence numbers could wrap with TCP_SACK and TCP_NEWRENO, resulting in
  failure to retransmit correctly.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/004_tcpsack.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="ipsec1">
***************
*** 165,171 ****
  &nbsp; <i>All architectures</i><br>
  Retransmitted TCP packets could get corrupted when flowing over an
  IPSEC ESP tunnel.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/003_espdata.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="bmap">
--- 165,171 ----
  &nbsp; <i>All architectures</i><br>
  Retransmitted TCP packets could get corrupted when flowing over an
  IPSEC ESP tunnel.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/003_espdata.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="bmap">
***************
*** 173,179 ****
  &nbsp; <i>All architectures</i><br>
  A local user can crash the system by reading a file larger than 64meg
  from an ext2fs partition.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/002_bmap.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="pfkey">
--- 173,179 ----
  &nbsp; <i>All architectures</i><br>
  A local user can crash the system by reading a file larger than 64meg
  from an ext2fs partition.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/002_bmap.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="pfkey">
***************
*** 183,189 ****
  system running an IPsec key management daemon like photurisd or isakmpd
  will cause the networking subsystem to stop working after a finite amount
  of time.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/001_pfkey.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="y2k">
--- 183,189 ----
  system running an IPsec key management daemon like photurisd or isakmpd
  will cause the networking subsystem to stop working after a finite amount
  of time.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/001_pfkey.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="y2k">
***************
*** 191,204 ****
  This patch corrects various OpenBSD/i386 2.5 problems with Y2K. The 2.6
  release (released at 1 Dec 1999) has this problem solved. This patch is
  just a workaround.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/i386/014_y2k.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="brooktree">
  <font color="#009000"><strong>RELIABILITY FIX</strong></font><br>
  If a user opened the brooktree device on a system where it did not exist,
  the kernel crashed.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/i386/013_brooktree.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="macutils">
--- 191,204 ----
  This patch corrects various OpenBSD/i386 2.5 problems with Y2K. The 2.6
  release (released at 1 Dec 1999) has this problem solved. This patch is
  just a workaround.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/i386/014_y2k.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="brooktree">
  <font color="#009000"><strong>RELIABILITY FIX</strong></font><br>
  If a user opened the brooktree device on a system where it did not exist,
  the kernel crashed.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/i386/013_brooktree.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li id="macutils">
***************
*** 206,219 ****
  The mac68k install utils were mistakenly left off the CD and out of
  the FTP install directories.  These tools have now been added to the
  FTP install directories.  See
! <a href="http://ftp.openbsd.org/pub/OpenBSD/2.5/mac68k/utils">
! http://ftp.openbsd.org/pub/OpenBSD/2.5/mac68k/utils</a>
  <p>
  <li id="powerpc_trap">
  <font color="#009000"><strong>RELIABILITY FIX</strong></font><br>
  Two problems in the powerpc kernel trap handling cause severe system
  unreliability.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.5/powerpc/001_trap.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  
--- 206,219 ----
  The mac68k install utils were mistakenly left off the CD and out of
  the FTP install directories.  These tools have now been added to the
  FTP install directories.  See
! <a href="https://ftp.openbsd.org/pub/OpenBSD/2.5/mac68k/utils">
! https://ftp.openbsd.org/pub/OpenBSD/2.5/mac68k/utils</a>
  <p>
  <li id="powerpc_trap">
  <font color="#009000"><strong>RELIABILITY FIX</strong></font><br>
  Two problems in the powerpc kernel trap handling cause severe system
  unreliability.
! <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.5/powerpc/001_trap.patch">
  A source code patch exists which remedies this problem.</a>
  <p>