http://blog.gmane.org/gmane.os.netbsd.announce hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.os.netbsd.announce/529 <pre>Dear all, please be advised that the machine hosting www.NetBSD.org, gnats.NetBSD.org and mail-index.NetBSD.org has a mainboard fault. www.NetBSD.org is currently being served by a mirror, gnats has been moved to a different server, and mail-index will also be moved. Since this is no planned action, it will take up to a day until nameserver caches clear and you see the current incumbents. Also, services may show some missing features until we get around to fixing everything. best regards, spz </pre> S.P.Zeidler 2013-05-21T19:07:47 http://comments.gmane.org/gmane.os.netbsd.announce/528 <pre>NetBSD 6.1 (and 6.0.2!) Released The NetBSD Project is pleased to announce NetBSD 6.1, the first feature update of the NetBSD 6 release branch. It represents a selected subset of fixes deemed important for security or stability reasons, as well as new features and enhancements. Simultaneously, the NetBSD Project is pleased to announce NetBSD 6.0.2, the second security/bugfix update of the NetBSD 6.0 release branch. It represents a selected subset of fixes deemed important for security or stability reasons, without new features. For more details, please see the 6.1 release notes and the 6.0.2 release notes. Complete source and binaries for NetBSD 6.1 and 6.0.2 are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, SUP, and other services may be found at http://www.NetBSD.org/mirrors/ . </pre> riz< at >NetBSD.org 2013-05-18T20:28:45 http://comments.gmane.org/gmane.os.netbsd.announce/527 <pre>Hi, cvsweb.NetBSD.org had been updated every 6 hours. I have modified cvsweb.NetBSD.org's ctontab and its repository is updated hourly now. Now I am watching its load. If you found a problem. Please tell me. Thank you. -- Ryo ONODERA // ryoon&lt; at &gt;NetBSD.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3 </pre> Ryo ONODERA 2013-04-27T12:51:21 http://comments.gmane.org/gmane.os.netbsd.announce/526 <pre>Dear members of the NetBSD community, EuroBSDcon is the European technical conference for users and developers of BSD-based systems. The conference will take place Thursday, September 26 through Sunday, September 29 at the Hilton (http://goo.gl/maps/hnACd) in St. Julian's, Malta (tutorials on Thursday and Friday, talks on Saturday and Sunday). Call for Talk Proposals ----------------------- The EuroBSDcon program committee is inviting BSD developers and users to submit innovative and original talk proposals not previously presented at other European conferences. Topics of interest to the conference include, but are not limited to applications, architecture, implementation, performance and security of BSD-based operating systems, as well as topics concerning the economic or organizational aspects of BSD use. Presentations are expected to be 45 minutes and are to be delivered in English. Call for Tutorial Proposals --------------------------- The EuroBSDcon program committee is also inviting qualified practitioners in their field to submit proposals for half or full day tutorials on topics relevant to development, implementation and use of BSD-based systems. Half-day tutorials are expected to be 2.5 to 3 hours and full-day tutorials 5 to 6 hours. Tutorials are to be held in English. Submissions ----------- Proposals should be sent by email to &lt;submission&lt; at &gt;eurobsdcon.org&gt;. They should contain a short and concise text description in about 100 words. The submission should also include a short CV of the speaker and an estimate of the expected travel expenses. Please submit each proposal as a separate email. Important dates --------------- The EuroBSDcon program committee is accepting talk and tutorial proposals until Monday, May 25 2013. Other important dates will be announced soon at the conference website http://2013.EuroBSDcon.org/. I am looking forward to your submissions and to see you on Malta, Joerg Sonnenberger On behalf of the EuroBSDcon Program Committee </pre> Joerg Sonnenberger 2013-03-28T15:07:46 http://comments.gmane.org/gmane.os.netbsd.announce/525 <pre>We're proud to announce the pkgsrc-2013Q1 release, the 50th quarterly pkgsrc release. For more information, please see http://mail-index.netbsd.org/tech-pkg/2013/04/01/msg011015.html Thomas </pre> Thomas Klausner 2013-04-01T15:55:34 http://comments.gmane.org/gmane.os.netbsd.announce/524 <pre> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-003 ================================= Topic:RNG Bug May Result in Weak Cryptographic Keys (REVISED) Version:NetBSD-current:affected prior to Mar 29th, 2013 NetBSD 6.0.1:affected NetBSD 6.0:affected NetBSD 5.2.*:not affected NetBSD 5.1.*:not affected Severity:Cryptography Weakness Fixed:NetBSD-current:Mar 29th, 2013 NetBSD-6-0 branch:Mar 29th, 2013 NetBSD-6 branch:Mar 26th, 2013 NetBSD 6.1 will contain the fix. NetBSD 6.0.2 will contain the fix. Please note that NetBSD releases prior to 5.1 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== Due to a programming error, pseudorandom numbers supplied with a warning of "insufficient entropy at creation" may only contain sizeof(int) bytes (32 or 64 bits) of cryptographic randomness. The first attempt to fix this bug, on January 26, 2013, contained a different programming error with the same effect. Technical Details ================= The NetBSD kernel uses an entropy pool to gather entropy from system events, hardware random number generators, environmental sensors, and other sources. This pool is never directly accessed by user processes nor by most kernel subsystems. Instead, the pool is used to key individual instances of a random stream generator based on the NIST SP 800-90 CTR DRBG, per-consumer. Each instance of the random stream generator itself mixes in local data believed to contain additional entropy, or at least to be difficult for an adversary to predict. As each stream generator runs, some additional such data are mixed in each time data are output. This additional entropy consists of kernel-private statistics such as per-thread context switch count and ticks on-cpu, as well as cpu cycle counter timestamps. When the kernel boots, it creates several instances of the random stream generator very early. Additional random number generator instances may be created relatively early by, for example, the sshd script generating keys when it first runs. Because generators created very early may be keyed when the system has very little entropy available, the system rekeys those generators as soon as a "minimum entropy" threshold is passed, where the entropy collection pool has enough bits to provide bits which are random in the cryptographic sense: computationally infeasible to distinguish from actual random noise. However, internally, the pool has an "entropy estimator" which counts how many bits have ever been put into the pool, for entropy consumers who care about information-theoretic randomness rather than cryptographic randomness. If a consumer asks for "GOOD" bits rather than "ANY" bits, the consumer will get only entropy-estimate worth of bits -- no more. The code for keying the stream generators which actually supply bits to kernel and user consumers requests GOOD bits and then, if it does not get as many as it wanted, and the user has indicated that cryptographic randomness is sufficient (for example, by opening /dev/urandom rather than /dev/random) requests ANY bits for the remainder. Other random-number-generator bugs have resulted in generators' output having a very small number of possible states. This bug is different: the stream generator's output has the expected range of possible states, but under some conditions, enough of the stream generator's input may be guessable that it might be practical to reproduce its output by brute force. The Original Bug ---------------- Due to a misplaced parenthesis, if insufficient GOOD bits were available to satisfy a request, the keying/rekeying code requested either 32 or 64 ANY bits, rather than the balance of bits required to key the stream generator. The result of this bug is that even after the minimum entropy threshold was reached, the generators for in-kernel and userspace consumers could in the worst case be keyed, or re-keyed, with as few as 32 bits (on 32 bit platforms) or 64 bits (on 64 bit platforms) of data, plus a 32-bit cycle counter value, plus the name of the generator (an LWP ID for userspace, a fixed string for kernel consumers), two 32-bit cycle counter snapshots, a count of context switches, and a count of LWP ticks on-CPU, plus stack noise. The most conservative estimate is that cryptographic keys produced in this way contain only 32 bits (on 32-bit platforms) or 64 bits (on 64-bit platforms) of entropy. A more optimistic estimate would assume that from an attacker's point of view, additional entropy (unpredictable bits, which must be guessed by brute force) are contained in the two cycle counter values and the LWP statistics. An additional consideration is that most consumers (including the OpenSSL and OpenSSH key-generation functions and utilities) access /dev/urandom via OpenSSL's RAND_bytes() function. This function itself mixes in two addtional timestamp values (though these are in seconds, not cycles), and also due to its implementation imposes a variable delay between the two in-kernel cycle-counter measurements mentioned above. Nonetheless, we urge users to proceed according to the conservative estimate, but provide the optimistic estimate in the interest of full disclosure. The Mistaken Fix (code from 2013-01-26 until 2013-03-29) -------------------------------------------------------- To fix the original bug, multiple instances of the code for keying stream generators were replaced by a single new function, cprng_entropy_try(). This function took a flag argument indicating whether the consumer wanted "hard" (information-theoretic) or "soft" (cryptographic) randomness. If "hard" randomness was requested, the function returned only GOOD bits, leaving the remainder of the caller-supplied buffer untouched. If "soft" randomness was requested, the function filled the rest of the caller-supplied buffer with ANY bits. The function always returned a count of only as many bytes of GOOD data as it could obtain. The code calling the new cprng_entropy_try() function, however, reversed the sense of the flag argument. This was missed by the original author and in code review. This could cause keying attempts originating from /dev/random device node opens to receive buffers with some GOOD and some ANY bits, but since the count of GOOD bits was correctly returned, the keying operations were retried before any data were output, and the result was merely less-efficient operation. However, keying attempts originating from /dev/urandom device node opens could receive only partially-filled buffers (with only as many GOOD bits as were available). The code for this case did not force an immediate rekey of the generator, but rather scheduled it for rekey as soon as bits were available in the entropy pool (but in any event, after its next use, since use of the generator invokes the rekeying code). Rekeying would occur with full entropy, but in the worst case, the next generator output might contain *only* entropy from the generator name (process ID) two cycle counter values, and kernel-private LWP statistics. If output was through OpenSSL's RAND_bytes function, additional entropy would come from that functions' implementation as discussed above. We do not know how to precisely quantify this entropy and urge that any keys generated on NetBSD-current or NetBSD 6 systems between 2013-01-26 and 2013-03-29 be regenerated, unless those systems are known to have not been in an "insufficent entropy" condition when the keys were generated (see discussion below). The correct fix always overwrites the entire caller-supplied buffer with output from the entropy pool and should be more robust against programmer error. Systems which never experience an "insufficient entropy" condition (for example, systems with hardware random number generators supported by NetBSD) are not impacted by this bug. All cryptographic keys generated on NetBSD 6 or NetBSD-current (prior to 2013-03-29) systems should be regenerated, unless it is certain that the system in question cannot have suffered a low-entropy condition when the keys were generated. In particular, since ECDSA ssh host keys are new in NetBSD 6 and are generated by /etc/rc.d/sshd at system boot if not yet present, it is likely that for systems that have been updated to NetBSD 6.0 or a netbsd-6 branch kernel before the fix date, ECDSA host keys have been considerably weakened by lack of actual randomness, especially since with little system uptime stack contents will be more predictable than later. For systems newly set up with NetBSD 6, all SSH host keys are suspect. Other persistent cryptographic secrets (for example, SSH or SSL keys of any type) generated using /dev/urandom on NetBSD 6 systems which may have had insufficient entropy at key generation time may be impacted and should be regenerated. Signature algorithms based on the discrete logarithm problem can disclose the private signing key if the nonce 'k' is predictable. However, DSA and ECDSA keys used (but not generated) on systems with this bug are believed to be safe. This is because the OpenSSL implementation of DSA signing feeds the digest of the message signed to the OpenSSL random-number generator as ancillary input, with the result that the nonce depends on the output of /dev/urandom, additional input used to seed the OpenSSL RAND_bytes() generator, and the message itself, and all bits from all inputs are well diffused across all bits output. Solutions and Workarounds ========================= Workaround: Don't generate cryptographic keys, and don't use random numbers for critical applications, on NetBSD 6 or NetBSD-current systems prior to 2013-01-27, unless the system has sufficient "GOOD" entropy. In practice, this means reading from /dev/random rather than /dev/urandom when using system entropy to generate cryptographic keys. Fix: Install a kernel containing the fix. The fastest way to do that, if you are running or can run a standard kernel built as part of the NetBSD release process, is to obtain the corresponding kernel from the daily NetBSD autobuild output and install it on your system. You can obtain such kernels from http://nyftp.netbsd.org/pub/NetBSD-daily/ where they are sorted by NetBSD branch, date, and architecture. To fix a system running NetBSD 6.0 or the stable NetBSD 6.0 branch, the most appropriate kernel will be the "netbsd-6-0" kernel. The "netbsd-6" kernel can also be used; this is the branch that will become NetBSD 6.1. To fix a system running NetBSD-current, the "HEAD" kernel should be used. In all cases, a kernel from an autobuild dated 20130329 or newer must be used to fix the problem. If you cannot use the autobuilt kernels, then for all affected NetBSD versions, you need to obtain fixed kernel sources, rebuild and install the new kernel, and reboot the system. The fixed source may be obtained from the NetBSD CVS repository. The following instructions briefly summarise how to upgrade your kernel. In these instructions, replace: ARCH with your architecture (from uname -m), and KERNCONF with the name of your kernel configuration file. NEWVERSION with the CVS version of the fix Versions of src/sys/kern/subr_cprng.c: BranchNEWVERSION --------------------------- HEAD1.16 netbsd-61.5.2.8 netbsd-6-01.5.2.3.4.2 To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -rNEWVERSION sys/kern/subr_cprng.c # ./build.sh kernel=KERNCONF # mv /netbsd /netbsd.old # cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd # shutdown -r now For more information on how to do this, see: http://www.NetBSD.org/guide/en/chap-kernel.html Thanks To ========= Ben Bucksch and Joachim Kuebart for discovering that the first attempt to fix the bug in fact didn't. Gregory Maxwell for pointing out that a discussion of ECDSA key use was needed in addition to the discussion of key generation. Thor Lancelot Simon for causing, finding, "fixing", and fixing the bug and helping with this advisory. Revision History ================ 2013-02-26Initial release 2013-03-07Title change; stronger cautionary text; fix improved. 2013-03-29Initial fix wasn't. Say so. Improve technical discussion. Add discussion of ECDSA/DSA key use. More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-003.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-003.txt,v 1.5 2013/03/29 23:18:18 christos Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (NetBSD) iQIcBAEBAgAGBQJRViMTAAoJEAZJc6xMSnBubd4QAJkAfHnu4omuVvtSQL68QA0J au7CX8VbLFdLT25pfUq5Sm8KBC5Kh9mSltA+nFfjEmSFG67jc32thZMre4DKj7Sf 6UuAYjWPT0PU0LCgCuPA4iytcIk9kXmrW82Ozki7DrWOX4z456KUdwedbL5fhzFl hbvaetm8KAtT27hM70uM6gsBQxa+HvdmSV5QZGgh3DRPpNGQC9f+oa9HyanqQMyM g/tuQbmf3mUOsiiRjDXphkvKjioqr9k3G8/yC8fNAo12yS3ZEq/LD+rQ3sKcf6lk L/Ja8AQ7nKGowu5ANtb/o0K6COil2oA60dkakvhMSYaX4MNnevwvScbVgN52RCuJ fL3uSZ38J9q/3SBm4cEf1ASE6sdHUzl7jhTZf2J2ZUw+rH3jjKAPtvFAYfRxRCUZ OsVL8NnGi592Y3ki0CVwNGfiHl8KnKDe+f+4fPI442/rWDsBO9/5qNGJdDaxx3Km 6a5q2CTwI8s9JaH71BZROnvAeD6NkoXL3SOSgNJi3UImE8fdL71ErmL7iHGBk9Uf Y7MLz9tfCWCU5B5Jp5y/38eF2iQFiiAccaJG5hGR+I3XwO975Ym4ZvtOhFmD0oal wDgP0PlLXb/Amo2ikOTfeuGXU/xhsh3z2tASUpKhaCruqcziYR/lRvn8b7ApSxNg NcTCy2lcAhJNiMBT82/X =yb+Y -----END PGP SIGNATURE----- </pre> NetBSD Security-Officer 2013-03-30T00:25:40 http://comments.gmane.org/gmane.os.netbsd.announce/523 <pre>Announcing NetBSD 6.1 Release Candidate 2 The second release candidate of NetBSD 6.1 is now available for download at: http://ftp.NetBSD.org/pub/NetBSD/NetBSD-6.1_RC2/ NetBSD 6.1 will be the first feature update for the NetBSD 6 branch. There are many new drivers, some new features, and many bug fixes! Fixes since RC1 include: - Various terminfo fixes (PR#46793, PR#47090, PR#47490, PR#47532) - Fixed a segfault in awk(1) (PR#47553) - Moved boottime50 and its associated sysctl into the compat module. (PR#47579) - Updated tzdata to 2013b, with the latest timezone info - Fixed a crash when the security.curtain sysctl is enabled (PR#47598) - Fixed some IPF locking issues - Fix a crash on statically-linked programs for NetBSD/alpha A complete list of changes can be found at: http://ftp.NetBSD.org/pub/NetBSD/NetBSD-6.1_RC2/CHANGES-6.1 Please help us test this and any upcoming release candidates as much as possible. Remember, any feedback is good feedback. We'd love to hear from you, whether you've got a complaint or a compliment. </pre> riz< at >NetBSD.org 2013-03-18T18:31:52 http://comments.gmane.org/gmane.os.netbsd.announce/522 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-003 ================================= Topic:RNG Bug May Result in Weak Cryptographic Keys Version:NetBSD-current:affected prior to Jan 26th, 2013 NetBSD 6.0.*:affected NetBSD 6.0:affected NetBSD 5.2.*:not affected NetBSD 5.1.*:not affected Severity:Cryptography Weakness Fixed:NetBSD-current:Jan 26th, 2013 NetBSD-6-0 branch:Jan 26th, 2013 NetBSD-6 branch:Jan 26th, 2013 NetBSD 6.1 will contain the fix. Please note that NetBSD releases prior to 5.1 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== Due to a programming error, pseudorandom numbers supplied with a warning of "insufficient entropy at creation" may only contain sizeof(int) bits of cryptographic randomness. Technical Details ================= When the kernel boots, it creates several instances of the kernel random number generator very early. Additional random number generator instances may be created relatively early by, for example, the sshd script generating keys when it first runs. Because generators created very early may be keyed when the system has very little entropy available, the system rekeys those generators as soon as a "minimum entropy" threshold is passed, where the entropy collection pool has enough bits to provide bits which are random in the cryptographic sense: computationally infeasible to distinguish from actual random noise. However, internally, the pool has an "entropy estimator" which counts how many bits have ever been put into the pool, for entropy consumers who care about information-theoretic randomness rather than cryptographic randomness. If a consumer asks for "GOOD" bits rather than "ANY" bits, the consumer will get only entropy-estimate worth of bits -- no more. The code for keying the stream generators which actually supply bits to kernel and user consumers requests GOOD bits and then, if it does not get as many as it wanted, and the user has indicated that cryptographic randomness is sufficient (for example, by opening /dev/urandom rather than /dev/random) requests ANY bits for the remainder. Due to a misplaced parenthesis, if insufficient GOOD bits were available to satisfy a request, the keying/rekeying code requested either 32 or 64 ANY bits, rather than the balance of bits required to key the stream generator. The result of this bug is that even after the minimum entropy threshold was reached, the generators for in-kernel and userspace consumers could in the worst case be keyed, or re-keyed, with as few as 32 bits (on 32 bit platforms) or 64 bits (on 64 bit platforms) of data, plus a 32-bit cycle counter value, plus the name of the generator (an LWP ID for userspace, a fixed string for kernel consumers), plus stack noise for the remainder. Systems which never experience an "insufficient entropy" condition (for example, systems with hardware random number generators supported by NetBSD) are not impacted by this bug. All cryptographic keys generated on NetBSD 6 or NetBSD-current (prior to 2013-01-27) systems should be regenerated, unless it is certain that the system in question cannot have suffered a low-entropy condition when the keys were generated. In particular, since ECDSA ssh host keys are new in NetBSD 6 and are generated by /etc/rc.d/sshd at system boot if not yet present, it is likely that for systems that have been updated to NetBSD 6.0 or a netbsd-6 branch kernel before the fix date, ECDSA host keys have being considerably weakened by lack of actual randomness, especially since with little system uptime stack contents will be more predictable than later. For systems newly set up with NetBSD 6, all ssh host keys are suspect. Other persistent cryptographic secrets (for example, SSH or SSL keys of any type) generated using /dev/urandom on NetBSD 6 systems which may have had insufficient entropy at key generation time may be impacted and should be regenerated. Solutions and Workarounds ========================= Workaround: Don't generate cryptographic keys, and don't use random numbers for critical applications, on NetBSD 6 or NetBSD-current systems prior to 2013-01-27, unless the system has sufficient "GOOD" entropy. In practice, this means reading from /dev/random rather than /dev/urandom when using system entropy to generate cryptographic keys. Fix: Install a kernel containing the fix. The fastest way to do that, if you are running or can run a standard kernel built as part of the NetBSD release process, is to obtain the corresponding kernel from the daily NetBSD autobuild output and install it on your system. You can obtain such kernels from http://nyftp.netbsd.org/pub/NetBSD-daily/ where they are sorted by NetBSD branch, date, and architecture. To fix a system running NetBSD 6.0 or the stable NetBSD 6.0 branch, the most appropriate kernel will be the "netbsd-6-0" kernel. The "netbsd-6" kernel can also be used; this is the branch that will become NetBSD 6.1. To fix a system running NetBSD-current, the "HEAD" kernel should be used. In all cases, a kernel from an autobuild dated 20130127 or newer must be used to fix the problem. If you cannot use the autobuilt kernels, then for all affected NetBSD versions, you need to obtain fixed kernel sources, rebuild and install the new kernel, and reboot the system. The fixed source may be obtained from the NetBSD CVS repository. The following instructions briefly summarise how to upgrade your kernel. In these instructions, replace: ARCH with your architecture (from uname -m), and KERNCONF with the name of your kernel configuration file. NEWVERSION with the CVS version of the fix Versions of src/sys/kern/subr_cprng.c: BranchNEWVERSION --------------------------- HEAD1.15 netbsd-61.5.2.7 netbsd-6-01.5.2.3.4.1 To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -rNEWVERSION sys/kern/subr_cprng.c # ./build.sh kernel=KERNCONF # mv /netbsd /netbsd.old # cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd # shutdown -r now For more information on how to do this, see: http://www.NetBSD.org/guide/en/chap-kernel.html Thanks To ========= Thor Lancelot Simon for causing, finding and fixing the bug and helping with this advisory. Revision History ================ 2013-02-26Initial release 2013-03-07Title change; stronger cautionary text; fix improved. More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-003.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-003.txt,v 1.3 2013/03/07 09:49:07 tonnerre Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (NetBSD) iQIcBAEBAgAGBQJROHDUAAoJEAZJc6xMSnBu1UMQALknWo5yifg477W84ToMiiB3 avDjLtcJB3cn4M6QycbNkfas1kaA6Qklj1FExIAh4yYRm8WBppRypjTJTkg8qmEE s3vhhXpN52lziJ8xjWtUT5NH5N2epkl/odxmSlZ5ae4FBQD7NRVltIJwWelTyOAq oJDtbWlHEBPaHEq3ftKzRBbkcxS/ZVbYfYjP9v4R6LlXhaK+3rZQ2XuTae7cbAX6 SA3EK3t0RR2AJt3qrRi2YD+26irdx6RTzHh+CoDdXhCzvj+nlrV+ha/xBPNdcqGR CwjPDuCeEuevDd3QH6VPC85YViJZ1YL0wqhElJToAVZcwQ5Se7RSk6xDXl4NPWta sSvxcKjpZoj2rcNSZd0kMZULM/a4UbDMbkn5gF3t6Vjqk4KmDcJl3pbMBN4A3/6L ah8frE1h33RWiyN5ExoZtkffjkMiQ9qr7elTvHciEVSXW00h+ghRda7oMGE8mUi4 dY7Pxw4kTczDkYXVu0FjQVT2R/4oxowAC7qKbDE02FhA5qoSdT9DLWHlxyyDAyno DD+HLsvxMqEVx8q9NVqHPQIF9qdDeQZd5vED1qZ1MvVir89hjNgoWUA05x/vAvsG vrxgzpAsphR4j7OYQmDekepsANyVUmHHh676wl/DhzNDzAsr+jsmrFEnKz0KXmRN Np4EdRSr8Th68ygfgMVT =28sX -----END PGP SIGNATURE----- </pre> NetBSD Security Officer 2013-03-07T21:46:37 http://comments.gmane.org/gmane.os.netbsd.announce/521 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-004 ================================= Topic:Vulnerabilities in grep Version:NetBSD-current:affected prior to Jan 5th, 2013 NetBSD 6.0.*:affected NetBSD 6.0:affected NetBSD 5.2.*:affected NetBSD 5.1.*:affected NetBSD 5.0.*:affected pkgsrc:textproc/grep prior to 2.13 Severity:Arbitrary Code Execution Fixed:NetBSD-current:Jan 5th, 2013 NetBSD-6-0 branch:Jan 13th, 2013 NetBSD-6 branch:Jan 13th, 2013 NetBSD-5-2 branch:Jan 13th, 2013 NetBSD-5-1 branch:Jan 13th, 2013 NetBSD-5-0 branch:Jan 13th, 2013 NetBSD-5 branch:Jan 13th, 2013 pkgsrc textproc/grep:grep-2.13 corrects this issue Please note that NetBSD releases prior to 5.0 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== Multiple integer overflows in GNU Grep before 2.11 might allow context-dependent attackers to execute arbitrary code via vectors involving a long input line that triggers a heap-based buffer overflow. This vulnerability has been assigned CVE-2012-5667. Technical Details ================= See http://openwall.com/lists/oss-security/2012/12/22/6 The PCRE aspect of the vulnerability does not apply to NetBSD. Solutions and Workarounds ========================= Workaround: Don't run grep against files of dubious provenance with lines of 2 GB, or longer. Fix: Replace grep with a fixed version. The fastest method to do that is to obtain a base.tgz matching your system from http://nyftp.netbsd.org/pub/NetBSD-daily/ dated 20130114 or later, and to extract ./usr/bin/egrep, ./usr/bin/fgrep and ./usr/bin/grep as well as ./rescue/egrep, ./rescue/fgrep and ./rescue/grep from it. The following instructions describe how to upgrade your grep binaries by updating your source tree and rebuilding and installing a new version of grep. The following files contain the fix: gnu/dist/grep/lib/getopt.c gnu/dist/grep/lib/regex.c gnu/dist/grep/src/ansi2knr.c HEAD1.2 netbsd-61.1.1.1.56.1 netbsd-6-01.1.1.1.62.1 netbsd-51.1.1.1.38.1 netbsd-5-21.1.1.1.64.1 netbsd-5-11.1.1.1.46.1 netbsd-5-01.1.1.1.42.1 gnu/dist/grep/src/dfa.c HEAD1.3 netbsd-61.2.56.1 netbsd-6-01.2.62.1 netbsd-51.2.38.1 netbsd-5-21.2.64.1 netbsd-5-11.2.46.1 netbsd-5-01.2.42.1 gnu/dist/grep/src/grep.c HEAD1.14 netbsd-61.13.8.1 netbsd-6-01.13.14.1 netbsd-51.12.4.1 netbsd-5-21.12.2.1 netbsd-5-11.12.12.1 netbsd-5-01.12.8.1 gnu/dist/grep/src/search.c HEAD1.4 netbsd-61.3.20.1 netbsd-6-01.3.26.1 netbsd-51.3.4.1 netbsd-5-21.3.28.1 netbsd-5-11.3.12.1 netbsd-5-01.3.8.1 To update from CVS, re-build, and re-install grep: # cd src # cvs update -d -P gnu/dist/grep # cd gnu/usr.bin/grep # make USETOOLS=no cleandir dependall # make USETOOLS=no install # cd ../../../usr.bin/ldd # make USETOOLS=no cleandir dependall # cd ../../rescue # make USETOOLS=no cleandir dependall # make USETOOLS=no install Thanks To ========= Joshua Rogers for identifying the problem in GNU grep. Ignatios Souvatzis and Alan Barrett for collaborating on a GPLv2 fix. Revision History ================ 2013-02-26Initial release More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-004.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-004.txt,v 1.1 2013/02/26 19:45:50 tonnerre Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (NetBSD) iQIcBAEBAgAGBQJRLRIBAAoJEAZJc6xMSnBuo0oQAKwd6+VU7q/XNA+GIh9yyn/a rXy0VmPx3uUQuMCdrzOmcXzyW9RzW9Gskv1Xgzo1T+HrTc7iQ9LMWtQfZSwPSYVk DEecyvIyAjeoEc4Ticbz2I0DxC0uRCDmMd2KhKQz/2C7XD6hUcDoVChUimNAeBxj l84VNPnyUzf3n2osaVA+1VRghsO1ITrF+c4Fxz1b1fX3C6wCOvi834BzEQGBH/LI o3nzsyC2w+0WiK0be3Nvt4dChlPNM7uiEqjS5833Zp3LauAxgKGhuQpsc34PL2V9 pA1chFw2Iay4Px1keYAczCbrmKHbGCZpO2WcGpiqW2Xe9S/yMiwGKN2MH3cTOVrm V6bz9UdyzfMz/TAlXwqC00c3AQ66FFXkNlHkdi6V5l3ZkLEKAxsZhtUziJxev3m9 E6/XZOT0BPggiG7+edJN6HgfzOGZZgonssUGXjjxk/R2Cu6HInbQ8jrcUaHdTOYR W+zRuCLU21klZWUZTqSLPH/csEq1q2dyWLkkP8HdveVlg/VzD4cpb+mAaAWa9iHD 6cEPNswYFqrpVneHUaeFdPe1mKTXfesOwxi6aHvQojZHnEiCdihvjSd28S+303po 5k3DQQiZYjFlzvHhXjXFGw9YgiXS3id/uEnm5aIJ505uZ7W0IzZuyfm0z5o7qqGj a7cXpgp2M9dYialzRVlE =3W1g -----END PGP SIGNATURE----- </pre> NetBSD Security Officer 2013-02-26T23:39:46 http://comments.gmane.org/gmane.os.netbsd.announce/520 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-002 ================================= Topic:kqueue related kernel panic triggered from userland Version:NetBSD-current:affected prior to Nov 24th, 2012 NetBSD 6.0:affected NetBSD 6.0.1:not affected NetBSD 5.1.*:not affected NetBSD 5.0.*:not affected NetBSD 5.0:not affected Severity:Local system crash Fixed:NetBSD-current:Nov 24th, 2012 NetBSD-6-0 branch:Nov 24th, 2012 NetBSD-6 branch:Nov 24th, 2012 Please note that NetBSD releases prior to 5.0 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== A user can panic the machine by calling kevent(2) on an unsupported file descriptor. Technical Details ================= A file descriptor that does not support kqueue(2) uses fnullop_kqfilter(9) to indicate that this operation is not supported. Unfortunately fnullop_kqfilter(9) returned 0 instead of an error, so the kernel crashed in the next kevent(2) trying to call a null event handler. fnullop_kqfilter(9) has been changed to return EOPNOTSUPP when the file descriptor does not support kqueue. Solutions and Workarounds ========================= The following versions contain the fix: src/sys/kern/kern_event.c HEAD1.78 netbsd-61.75.2.1 netbsd-6-01.75.6.1 src/sys/kern/kern_descrip.c HEAD1.219 netbsd-61.218.2.1 netbsd-6-01.218.8.1 For all affected NetBSD versions, you need to obtain fixed kernel sources, rebuild and install the new kernel, and reboot the system. The fixed source may be obtained from the NetBSD CVS repository. The following instructions briefly summarize how to upgrade your kernel. In these instructions, replace: ARCH with your architecture (from uname -m), and KERNCONF with the name of your kernel configuration file. To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -d -P src/sys/kern/kern_event.c # cvs update -d -P src/sys/kern/kern_descrip.c # ./build.sh kernel=KERNCONF # mv /netbsd /netbsd.old # cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd # shutdown -r now For more information on how to do this, see: http://www.NetBSD.org/guide/en/chap-kernel.html Thanks To ========= Thanks to Christos Zoulas for fixing this problem. Revision History ================ 2013-02-26Initial release More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-002.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-002.txt,v 1.1 2013/02/26 18:58:13 tonnerre Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (NetBSD) iQIcBAEBAgAGBQJRLRHwAAoJEAZJc6xMSnBukmUQAJ/JxHKIy3Mc05korW03dKzo Zt/f3SaAHDXu00mEOjsbCbX92G0+eY9G5QetmpFPeu+GjdkKOoexD94Nck7JWVWU 0iIHlJnunnPcvXszqvQLUoOx4Iej0VvW6JynVhbHO9asCWyS6yqeuXka4IJoMrXb A1hySfXqmvvOyrRpp8+6mrmv2sl0Vzne8X7sJUwBt35Z6EB7uLd3Pw6+uyRpPWkN DPg7I/B1ey/MRof/CKfTlvnkSoiSzo/utrOiaqseBici6QxXxDOfmlo4Vd9GjCS4 GJ3C9ushHgW6+6VwrpkX/ku0WYRbpS9Sf/Uem0CMONZpwOxOQgpvviHaxobCTrCf GxyZahkuWM3HTcg3Ht+y65wROC7ruHbBrFxS6iAYnjMJA8/PtvNAP1+N08cDbdB+ qXdXrKxY1dnEVqDa6YRCVb2+FccpXp7etTRfxVv3yyiZu9Dr1IlywpqLhpzshs9c wFkgD3/sIy7WV05/DrWXi0GHXqkUkpWtRgzHH5zYFi3Buu4FuOYC/2U0YaoLM6KE ddUr5zawlTzOdrXB2ztYHra0y26M7ntiyNyDF5Laj5yUzlBBxXR1y2XMhHH7o/v4 vUrkavrmTXj0Y8bj+LiqRfcnBUR2hKXcRKqekM/RKNJuJ/kkKwPl25f4jGXeY/ng nDDi2DtzYyBucGqqSPwr =7s47 -----END PGP SIGNATURE----- </pre> NetBSD Security Officer 2013-02-26T23:38:59 http://comments.gmane.org/gmane.os.netbsd.announce/519 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-003 ================================= Topic:Pseudo-Random bits weaker than expected Version:NetBSD-current:affected prior to Jan 26th, 2013 NetBSD 6.0.*:affected NetBSD 6.0:affected NetBSD 5.2.*:not affected NetBSD 5.1.*:not affected Severity:Cryptography Weakness Fixed:NetBSD-current:Jan 26th, 2013 NetBSD-6-0 branch:Jan 26th, 2013 NetBSD-6 branch:Jan 26th, 2013 NetBSD 6.1 will contain the fix. Please note that NetBSD releases prior to 5.1 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== Due to a programming error, pseudorandom numbers supplied with a warning of "insufficient entropy at creation" may only contain sizeof(int) bits of cryptographic randomness. Technical Details ================= When the kernel boots, it creates several instances of the kernel random number generator very early. Additional random number generator instances may be created relatively early by, for example, the sshd script generating keys when it first runs. Because generators created very early may be keyed when the system has very little entropy available, the system rekeys those generators as soon as a "minimum entropy" threshold is passed, where the entropy collection pool has enough bits to provide bits which are random in the cryptographic sense: computationally infeasible to distinguish from actual random noise. However, internally, the pool has an "entropy estimator" which counts how many bits have ever been put into the pool, for entropy consumers who care about information-theoretic randomness rather than cryptographic randomness. If a consumer asks for "GOOD" bits rather than "ANY" bits, the consumer will get only entropy-estimate worth of bits -- no more. The code for keying the stream generators which actually supply bits to kernel and user consumers requests GOOD bits and then, if it does not get as many as it wanted, and the user has indicated that cryptographic randomness is sufficient (for example, by opening /dev/urandom rather than /dev/random) requests ANY bits for the remainder. Due to a misplaced parenthesis, if insufficient GOOD bits were available to satisfy a request, the keying/rekeying code requested either 32 or 64 ANY bits, rather than the balance of bits required to key the stream generator. The result of this bug is that even after the minimum entropy threshold was reached, the generators for in-kernel and userspace consumers could in the worst case be keyed, or re-keyed, with as few as 32 bits (on 32 bit platforms) or 64 bits (on 64 bit platforms) of data, plus a 32-bit cycle counter value, plus the name of the generator (an LWP ID for userspace, a fixed string for kernel consumers), plus stack noise for the remainder. Systems which never experience an "insufficient entropy" condition (for example, systems with hardware random number generators supported by NetBSD) are not impacted by this bug. Given that ECDSA ssh host keys are new in NetBSD 6 and get generated by /etc/rc.d/sshd at system boot if not yet present, it is likely that for systems that have been updated to NetBSD 6.0 or a netbsd-6 branch kernel before the fix date, ECDSA host keys have being considerably weakened by lack of actual randomness, especially since with little system uptime stack contents will be more predictable than later. Also, for systems newly set up with NetBSD 6, all ssh host keys are suspect. Other persistent cryptographic secrets (for example, SSH or SSL keys of any type) generated using /dev/urandom on NetBSD 6 systems which may have had insufficient entropy at key generation time may be impacted and should be regenerated. Solutions and Workarounds ========================= Workaround: Don't generate cryptographic keys, and don't use random numbers for critical applications, unless the system has sufficient "GOOD" entropy. In practice, this means reading from /dev/random rather than /dev/urandom when using system entropy to generate cryptographic keys. Fix: Build and install a kernel containing the fix. For all affected NetBSD versions, you need to obtain fixed kernel sources, rebuild and install the new kernel, and reboot the system. The fixed source may be obtained from the NetBSD CVS repository. The following instructions briefly summarise how to upgrade your kernel. In these instructions, replace: ARCH with your architecture (from uname -m), and KERNCONF with the name of your kernel configuration file. NEWVERSION with the CVS version of the fix Versions of src/sys/kern/subr_cprng.c: BranchNEWVERSION --------------------------- HEAD1.15 netbsd-61.5.2.7 netbsd-6-01.5.2.3.4.1 To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -rNEWVERSION sys/kern/subr_cprng.c # ./build.sh kernel=KERNCONF # mv /netbsd /netbsd.old # cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd # shutdown -r now For more information on how to do this, see: http://www.NetBSD.org/guide/en/chap-kernel.html Thanks To ========= Thor Lancelot Simon for causing, finding and fixing the bug and helping with this advisory. Revision History ================ 2013-02-26Initial release More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-003.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-003.txt,v 1.2 2013/02/26 19:40:22 tonnerre Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (NetBSD) iQIcBAEBAgAGBQJRLRH4AAoJEAZJc6xMSnBus3sP/2/Fi3hF86JD9ioukISHNeCf 1SIQuwUAAPgU3nTZMTb5PNCRtgemfyAnuS+WuHZYUnALTmDmjIG5hBgg0XtPkEvF ngOiVwK5pu14RaErjDl+FKJqCa558WjVsYcuGpUkmTITO+Uf7tJUPStPYnu5/xnk 8QVPtx4QZJ91mX3HLgjIPYgTNNGxiP9ib027PdeHQMVI38J+jZ61Ajv25JBZGqlM lhRR10+yMNMWurzvoKOZ4rQcAQjlGpbA6GjYZU2Fon4TL3NwLLyU1GEQ6kSEs4PJ JZ4z4xhmm+xpgOlfjE86I6wKovB/CjXKqBTI7jnLP2f1zQlvORmDUEPGzxzBpTCR iZ4qHJycAxwVLzYMMt58kiJXUjdDJXsGpbti512y6RcswJI7TC58n7wYlIgMIudf OUYkC+ZWRzyizW8Xh2Jy/hmVMZ4DPkX7dIWWv2HUR6qqT5NMo0dtCn2g3XVRS8Xf GalkqJCFo1xVQ3fp14+lxzk9odNGtE+Br/XYtl6qngUt4hmBPMeKtKqRjgxsUYWQ 4rbTuTsatTO03YiUuyIc+59GFnK1WphRHR4urvTRnEP1wNZCC41NSLtlz9GmqY5Y y9EeAPWNsQih23huSULsc6hQMuBxPmasfLRezWGFYrOlaEAG3WpJPZm8eGuloOID q2YFpY/XbKFFRmgyeVMj =zWDv -----END PGP SIGNATURE----- </pre> NetBSD Security Officer 2013-02-26T23:39:26 http://comments.gmane.org/gmane.os.netbsd.announce/518 <pre>The first release candidate of NetBSD 6.1 is now available for download at: http://ftp.NetBSD.org/pub/NetBSD/NetBSD-6.1_RC1/ NetBSD 6.1 will be the first feature update for the NetBSD 6 branch. There are many new drivers, some new features, and many bug fixes! Highlights include: - Bugfixes and feature improvements to NPF, the NetBSD Packet Filter - Improvements to several ARM platforms, including Raspberry Pi which now has nearly-complete support. - Support for dtrace on amd64 - MIPS ports switched to gdb 7.3.1, gdb6 removed - Additional device support in key drivers including wm(4), uftdi(4), mfi(4), bge(4), aac(4), tlp(4) and others. - Various port-specific improvements to the amiga, arm, sparc64 and x68k ports. A complete list of changes can be found at: http://ftp.NetBSD.org/pub/NetBSD/NetBSD-6.1_RC1/CHANGES-6.1 Please help us test this and any upcoming release candidates as much as possible. Remember, any feedback is good feedback. We'd love to hear from you, whether you've got a complaint or a compliment. </pre> riz< at >NetBSD.org 2013-02-22T22:00:19 http://comments.gmane.org/gmane.os.netbsd.announce/517 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-001 ================================= Topic:kernel panic triggered from userland Version:NetBSD-current:affected prior to Dec 29th, 2012 NetBSD 6.0.*:affected NetBSD 6.0:affected NetBSD 5.1.*:not affected NetBSD 5.0.*:not affected NetBSD 5.0:not affected Severity:Local system crash Fixed:NetBSD-current:Dec 29th, 2012 NetBSD-6-0 branch:Jan 7th, 2013 NetBSD-6 branch:Jan 7th, 2013 Please note that NetBSD releases prior to 5.0 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== A user can panic the machine by using ktrace or ktruss on a program sleeping in recvmsg. Technical Details ================= If an untraced process sleeps in recvmsg/sendmsg, the syscall does not allocate an iov structure for ktrace. When tracing is then enabled and the process wakes up, it crashes the kernel. A local user could intentionally crash the machine by running a program that entered the required sleep state, and then call ktrace or ktruss on it. Solutions and Workarounds ========================= The following versions contain the fix: src/sys/kern/uipc_syscalls.c HEAD1.158 netbsd-61.154.2.2 netbsd-6-01.154.2.1.4.1 For all affected NetBSD versions, you need to obtain fixed kernel sources, rebuild and install the new kernel, and reboot the system. The fixed source may be obtained from the NetBSD CVS repository. The following instructions briefly summarise how to upgrade your kernel. In these instructions, replace: ARCH with your architecture (from uname -m), and KERNCONF with the name of your kernel configuration file. To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -d -P sys/kern/uipc_syscalls.c # ./build.sh kernel=KERNCONF # mv /netbsd /netbsd.old # cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd # shutdown -r now For more information on how to do this, see: http://www.NetBSD.org/guide/en/chap-kernel.html Thanks To ========= Thanks to Michael van Elst for finding and fixing this problem. Revision History ================ 2013-01-28Initial release More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-001.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-001.txt,v 1.1 2013/01/28 11:12:51 tonnerre Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRBl1CAAoJEAZJc6xMSnBuXdgQAICblrbsfIYWj59b/y2BpyDM v1m01WzTeAxWXhpq1eMZg7RFm/IDWcqxZ5RbmH11U4htClz5i7LKHMv8M1ttkyaq Sus84jnQhOsU9peCeVjhnFnXuTogzaw1pCREHmCT7yqInLSc5TrYCvq3rDsWMm8Y VT0ht6ri9De7woch5IIMkDSK2QKGFba2z0X0OgBsXvrDDoWWj4G7FLiYlWSe1TLN nGvxsoGjeQjHg51wzqkEbVve5eCrZh0MKrcG9UUOZZDI0vbUCCXcvZgE/cfS7alk I3Naak3yCnNFbUn9lB5Wu1svbZ92jHPyOyIZO3WrOvqHkkEqQci6Wgh5U9cBGlTI PEZiRQ8CjhsRs9yIfm4p1ArMoB5DzK6kCeb7JfTcSUp/8OfRjQqVw3YINYgKLQ7j agLGt1XT79sEh6yuraJaneUXLiuOVhVpM3+eIYtWGwwb9xFUxTJRi0p0b77ulXqI KLTHYPUa1v6gSUc7QO41tdz0veGAG7O5LVr5gG77GcwJ3BaWwDHUJJ3Tcf5tPO8v wuZZsbpX2Y50zQ3h+QbgOMEGWeyKWxvSCfDFvtCUA8PxeUOmR+/oiWfMxUDLG1tW jkLdJ94wXvTyCSYlQBZD5tikVDI2o5LCHd5a9Da8GHQvyhKO64s04z5T9U2pIKxv guqOI+FKmOMN/mvRYUJd =2yOG -----END PGP SIGNATURE----- </pre> NetBSD Security Officer 2013-01-29T00:40:11 http://comments.gmane.org/gmane.os.netbsd.announce/516 <pre> pkgsrc-2012Q4 ============= The pkgsrc team is proud to announce that pkgsrc-2012Q4 is available. This release marks the 15th birthday of pkgsrc (the first entries were added in October 1997), and this release includes many new packages and updates. pkgsrc is a framework allowing third-party software to be built, installed, and managed in a consistent, logical and easy manner. The resulting binary packages can be manipulated using binary package managers like pkgin and nih. The framework is portable across operating systems, making it easy to support diverse systems from Windows to BSD, and including Linux and Mac OS X - see below for a complete list of platforms. pkgsrc releases take place at the end of every quarter. The pkgsrc-2012Q4 release is the 49th release of pkgsrc. Numbers of Packages =================== The latest figures we have for different platforms, include: 11942 total packages for NetBSD-current/amd64 11229 binary packages built with gcc for NetBSD-current/amd64 11336 binary packages built with clang for NetBSD-current/amd64 10265 binary packages for Linux-3.2.7/x86_64 9519 binary packages for SunOS-5.11/x86_64 11105 binary packages for Dragonfly-3.3/i386 10985 pkgsrc entries 178 packages have been added this quarter 30 packages have been removed this quarter 1259 packages have been updated this quarter 2 packages have been renamed this quarter It is interesting to note that, according to pkgsrc-bulk figures on NetBSD-current/amd64 bulk builds, more packages now build with clang than with gcc - thanks to Joerg Sonnenberger. These numbers may not compare exactly to other (binary) packaging systems; some packaging systems split large packages like boost up into multiple packages, while others keep unused and unbuildable packages. A large amount of work has been done this quarter to building packages on different platforms with newer compilers. The total number of packages has actually gone down since the summer, mainly due to the removal of support for two older versions of python. New packages include contao30, deforaos, ffmpeg-1.0.1, freeswitch sounds, json-c, KeePass, moneyguru, motif-2.3.4, otptool, podcastdl, polysh, postgres92, python-3.3, sun-jdk7, sun-jre7, swig2 Notable updates include asterisk, automake, bacula, bind, boost, cairo, cdrtools, cflow, coccinelle, cscope, curl, django, dovecot, drupal7, fetchmail, firefox, gcc47, git (as scmgit), glusterfs, gnome3, gnuplot, gnustep, gv, heimdal, hydrogen, ikiwiki, jenkins, kde, knot, libevent, libreoffice, mercurial, modular-xorg-server, mono, ng, openjpeg, openldap, openmpi, opensc, pidgin, pkgin, png, postfix, postgres91, postgresql92, qrencode, R, roundcube, samba, seamonkey, sqlite3, thunderbird, Transmission, typo3, valgrind, viewvc webmin, wireshark, xlockmore, xterm, xulrunner Pkgsrc-security =============== One neat feature of pkgsrc is its ability to sort package versions based on the version numbers. It's used in audit-packages, to report on any installed packages which may have security vulnerabilities in them. pkgsrc-security&lt; at &gt;pkgsrc.org maintains lists of vulnerable packages, along with reference URLs relating to the exposure. We thank OBATA Akio, Daniel Horecki, Guillaume Lasmayous, and Tim Zingelman for their hard work. Sample output from audit-packages is shown below: % audit-packages Package libtasn1-2.11 has a local-system-compromise vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1569 Package gnutls-2.12.14nb1 has a local-system-compromise vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1573 % Getting pkgsrc ============== While more information can be found in http://www.netbsd.org/docs/pkgsrc/getting.html tar files for pkgsrc, along with checksums, can be found at http://ftp.netbsd.org/pub/pkgsrc/pkgsrc-2012Q4/ and anonymous cvs can be used: cvs -z3 -q -d anoncvs&lt; at &gt;anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-2012Q4 -P pkgsrc Package of the Quarter ====================== Thomas Klausner nominated pkgsrc/print/lilypond, a music typesetter, Jared Mcneill nominated samba (used with pam-mkhomedir to integrate with Active Directory), and Jeff Rizzo nominated pkgin, rsync and zsh as being ubiquitous on machines he used. About pkgsrc ============ The strengths of building packages from source are that: + not only is the provenance of source code checked (by using multiple checksums), with pkgsrc, the version of source code you are working with is the same that other developers and users have. + patches are maintained in a central repository, and, again, are checked at patch application time by using digests. The patches which are applied to the sources being built are the same ones which are known to be used and proved by other pkgsrc users (not necessarily on the same platform) + by building from source, all doubts about compilers, build practices, source code cleanliness, and packaging differences are removed. Digital signatures of binary packages, while useful in themselves, only prove certain aspects of binary package provenance. (pkgsrc has had signed packages since 2001.) + it may be difficult or impossible to find a pre-built package for the operating system or architecture + a pre-built package may have further or conflicting pre-requisites, which are themselves difficult to find or build. By building everything, including pre-requisites, a from-source packaging system can ensure that pre-requisites are present and integrated + local or site options which span packages can be set in a standard way + pkgsrc includes a framework for linking only with pre-requisite packages which are explicitly named; no "build system package" leakage can take place At the present time, pkgsrc supports 19 platforms: AIX BSDOS Darwin/Mac OS X DragonFly FreeBSD FreeMiNT HPUX Haiku IRIX Interix/SFU/SUA Linux Minix3 MirBSD NetBSD OSF1 OpenBSD QNX SunOS/Solaris/SmartOS UnixWare Complete dependency and pre-requisite package information is held and used by the package management software - if packages rely on other packages to function properly, that pre-requisite will be built, installed and managed as part of the package installation process. Binary packages can be managed using pkgin. Alistair Crooks On behalf of the pkgsrc developers Thu Jan 3 09:51:17 UTC 2013 </pre> Alistair Crooks 2013-01-11T06:33:52 http://comments.gmane.org/gmane.os.netbsd.announce/515 <pre>The NetBSD Project is pleased to announce NetBSD 6.0.1, the first security/bugfix update of the NetBSD 6.0 release branch. It represents a selected subset of fixes deemed important for security or stability reasons. For more details, please see the 6.0.1 release notes at http://www.NetBSD.org/releases/formal-6/NetBSD-6.0.1.html . Complete source and binaries for NetBSD 6.0.1 are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, SUP, and other services may be found at http://www.NetBSD.org/mirrors/. </pre> riz< at >NetBSD.org 2012-12-26T16:37:00 http://comments.gmane.org/gmane.os.netbsd.announce/514 <pre>Beginning at noon New York time (17:00 UTC) on December 26, and lasting approximately two days, nyftp.netbsd.org will be offline due to an overhaul of the the air conditioning system serving our New York racks. The periodic autobuilds of NetBSD and pkgsrc will also be unavailable for the duration of the chiller maintenance. Everything should be back online before the new year. </pre> Thor Lancelot Simon 2012-12-25T21:25:28 http://comments.gmane.org/gmane.os.netbsd.announce/513 <pre>Hi all, The hardware is currently not turning on. A mirror will play stand-in, but that mirror doesn't have the gnats or mail-index databases, so these won't be working. We'll restore service as soon as possible (all else failing: we have backups). regards, spz </pre> S.P.Zeidler 2012-12-06T19:32:28 http://comments.gmane.org/gmane.os.netbsd.announce/512 <pre>The first release candidate of NetBSD 5.2 is now available for download at: http://ftp.NetBSD.org/pub/NetBSD/NetBSD-5.2_RC1/ NetBSD 5.2 is intended for those who have an application using NetBSD 5.0.x or 5.1.x who don't want the churn of upgrading to NetBSD 6.0, but who would like bug fixes and some stable new features. There have been a number of changes since 5.1. See src/doc/CHANGES-5.2 for the full list. Those of you who prefer to build from source can continue to follow the netbsd-5 branch, but the netbsd-5-2-RC1 tag is available as well. Please help us test this and any upcoming release candidates as much as possible. Remember, any feedback is good feedback. We'd love to hear from you, whether you've got a complaint or a compliment. On behalf of NetBSD Release Engineering, +j </pre> riz< at >NetBSD.org 2012-11-14T18:33:49 http://comments.gmane.org/gmane.os.netbsd.announce/511 <pre>.... hope this reachs to you this time, Herb .... Hi, all, I and our team in Sanctum Networks have been making NetBSD port for Tile-GX 64bit multi-core processor and it now has reached to the stage running a single user mode shell. We will continue our efforts to fulfill the device drivers and SMP capabilities. We are planning to publish the code when it gets mature enough for public use. Toru Nishimura / Sanctum Networks, Bangalore India / nisimura&lt; at &gt;netbsd.org --- Type t in 3 seconds to run thorough POST tests, q to run quick tests... Thorough POST tests will be run. msh0 0123 msh1 0123 (0,0) Tilera Hypervisor, version 4.0.2.145127 (source dist) 2012-10-26 19:37:50 (0,0) Built by girish on Wed Oct 31 20:01:10 2012 from /home/girish/NetBSD/hvc/netbsd.hvc, /home/girish/NetBSD with CHIP_VERSION=10 CHIP_WIDTH=6 CHIP_HEIGHT=6 WATCHDOG=1 Symbols table: PA 0xc8_0038 - 0x3_63a8 Strings table: PA 0xcc_0038 - 0x2_3608 Hello NetBSD/tile! Topology: 6,6 &lt; at &gt; 0,0 (cpumask= 0xfffffffff) Physical memory map: Memory [0] 0 / 1fc000000 &lt; at &gt; cntrl# 0 Memory [1] 4000000000 / 200000000 &lt; at &gt; cntrl# 1 Virtual memory map: Memory [0] 0 / 20000000000 Memory [1] fffffe0000000000 / 1fc00000000 Memory [2] ffffffff80000000 / 80000000 Memory layout: 0x0000020000000000 = MEM_HOLE_BEGIN 0xfffffe0000000000 = MEM_HOLE_END 0x0000020000000000 = HALF_VA_SPACE 0xfffffe0000000000 = VM_MIN_KERNEL_ADDRESS 0xfffffff400000000 = VM_MAX_KERNEL_ADDRESS 0xfffffff400000000 = FIXADDR_BASE 0xfffffff500000000 = FIXADDR_TOP 0xfffffff500000000 = HMAP0_BASE 0xfffffff600000000 = HMAP0_TOP 0xfffffff600000000 = HMAP1_BASE 0xfffffff700000000 = HMAP1_TOP 0xfffffff700000000 = MEM_SV_START 0xfffffff800000000 = MEM_HV_START FIXMAP: 0xfffffff400000000 0xfffffff500000000 fixmap 0xfffffff500000000 0xfffffff700000000 huge memory ASID map: ASID Range [0] 0 / 255 command= &lt;TLR_NETWORK=auto &gt; Loaded initial symtab at 0xfffffe0000c80038, strtab at 0xfffffe0000cc0038, # entries 9234 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 6.0_BETA2 (GENERIC-$Revision: 1.343 $) #177: Wed Oct 31 19:58:56 IST 2012 girish&lt; at &gt;lxeagle:/e/home/girish/NetBSD/tile/work/decan/build/tile/obj/sys/arch/tile/compile/INSTALL tilegx 1200MHz avail memory = 16256 MB cprng kernel: WARNING insufficient entropy at creation. mainbus0 (root) cpu0 at mainbus0: TILERA tilegx Rev. 10.0, 64bit cpu0: 1200.00MHz (hz cycles = 12000000, delay divisor = 1200) cpu0: L1 I-Cache 32KB/64 2-ways associative cpu0: L1 D-Cache 32KB/64 2-ways associative cpu0: L2 Cache 256KB/64 8-ways associative imesh0 at mainbus0 hvc0 at imesh0: virtual console eeprom0 at imesh0: i2cm0 at imesh0: rshim0 at imesh0: tgpio0 at imesh0: pka0 at imesh0: trng0 at imesh0: mpipe0 at imesh0: gbe1 at mpipe0 unit 1: 1000Mbps auto, 00:1a:ca:00:9f:25 wdt0 at imesh0: set for 20 sec. cprng sysctl: WARNING insufficient entropy at creation. boot device: &lt;unknown&gt; root on md0a dumps on md0b mountroot: trying nfs... mountroot: trying ffs... root file system type: ffs WARNING: preposterous TOD clock time WARNING: using filesystem time WARNING: CHECK AND RESET THE DATE! init path (default /sbin/init): init: copying out flags `-s' 3 init: copying out path `/sbin/init' 11 # ls -l total 5669 -rw-r--r-- 1 root wheel 2823 Jan 1 09:51 .profile-sysinst drwxr-xr-x 2 root wheel 512 Jan 1 11:05 bin drwxr-xr-x 2 root wheel 2560 Jan 1 09:51 dev drwxr-xr-x 2 root wheel 512 Jan 1 09:51 etc drwxr-xr-x 2 root wheel 512 Jan 1 09:51 kern drwxr-xr-x 3 root wheel 512 Jan 1 09:51 libexec drwxr-xr-x 2 root wheel 512 Jan 1 09:51 mnt drwxr-xr-x 2 root wheel 512 Jan 1 09:51 mnt2 drwxr-xr-x 2 root wheel 512 Jan 1 11:05 sbin -r-xr-xr-x 53 root wheel 2785808 Jan 1 09:51 sysinst -r--r--r-- 1 root wheel 25168 Jan 1 09:51 sysinstmsgs.de -r--r--r-- 1 root wheel 24230 Jan 1 09:51 sysinstmsgs.es -r--r--r-- 1 root wheel 25373 Jan 1 09:51 sysinstmsgs.fr -r--r--r-- 1 root wheel 21868 Jan 1 09:51 sysinstmsgs.pl drwxr-xr-x 2 root wheel 512 Jan 1 09:51 targetroot drwxrwxrwt 2 root wheel 512 Jan 1 09:51 tmp drwxr-xr-x 6 root wheel 512 Jan 1 09:51 usr drwxr-xr-x 6 root wheel 512 Jan 1 09:51 var # --- </pre> Toru Nishimura 2012-11-08T04:29:44 http://comments.gmane.org/gmane.os.netbsd.announce/510 <pre>With the release of NetBSD 6.0, we bid a fond farewell to older releases, the NetBSD 4.x series. While we have many plans for active support of the most recent (6.x) and next most recent (5.x) release branches, 4.x is coming to the end of its supported life. As of November 17, one month after the 6.0 release, the following branches will no longer be maintained: * netbsd-4-0 * netbsd-4 This means: * There will be no more pullups to the branches (even for security issues) * There will be no security advisoriesany of the 4.x releases * The existing 4.x releases on ftp.NetBSD.org will be moved into /pub/ NetBSD-archive/ We are giving these remaining few weeks of support to give people time to migrate their machines to the newer release. We may choose to issue security advisories and/or release patches if a security issue should arise before November 17. Here's hoping NetBSD 6 serves you as well as, or preferably better than, NetBSD 4 did! </pre> riz< at >NetBSD.org 2012-10-27T03:55:01 http://comments.gmane.org/gmane.os.netbsd.announce/509 <pre>Dear All, NetBSD 6.0 introduces NPF - a NetBSD packet filter. Please find a short presentation and a quick overview on how to use it: http://www.netbsd.org/~rmind/pub/npf_presentation_netbsd_6.pdf http://www.netbsd.org/~rmind/pub/npf_manual_netbsd_6.pdf Thank you. </pre> Mindaugas Rasiukevicius 2012-10-17T17:39:13 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.announce