A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_7 2026-02-27T20:32:48+00:00 2026-02-27T20:32:48+00:00 bluhm 2026-02-27T20:32:48+00:00 urn:sha1:140c0395d7c1ac0617c23e5b1b8e3401cd6b0f58 mktemp(3) type operations, unveil "/" "r" for reading all over the tree, and pledge "stdio rpath wpath cpath" to permit both unveils subject to their own limitations. pledge "rpath tmppath" is replace with unveil "/" "r", unveil "/tmp" "rwc", and "rpath wpath cpath" from deraadt@; ok semarie This was using pledge "tmppath" with "rpath wpath cpath". The "tmppath" is not needed. from deraadt@; ok semarie and others uses tmpfile(), which is why it used "tmppath", which is why it now needs "rpath wpath cpath" from deraadt@; spotted by brynet Instead of pledge "tmppath rpath", setup a "rwc" unveil on "/tmp", a "r" unveil on "/", and then pledge "rpath wpath cpath". from deraadt@; ok semarie and others This is using pledge "tmppath" with "rpath wpath cpath". The "tmppath" is not needed. from deraadt@; ok semarie and others These programs are using pledge "tmppath" with "rpath wpath cpath". The "tmppath" is not needed. from deraadt@; ok semarie and others Use unveil() instead of pledge "tmppath". There is a bit of bulldozering here to handle the many codeflows regarding output files, and I hope ingo improves it later. from deraadt@; Some help with regression validation from job nc(1) has the more crazy unveil + pledge configuration based upon argument flags. I think this correctly replaces "tmppath" with an unveil. from deraadt@ Since this program is "rpath wpath cpath", it does not need to use "tmppath" from deraadt@; ok op replace pledge "tmppath" with unveil "/tmp" "rwc" and "rpath wpath cpath". from deraadt@; ok ok this is errata/7.7/021_tmppath.patch.sig 2025-10-23T15:27:27+00:00 tb 2025-10-23T15:27:27+00:00 urn:sha1:b087cd0400f51020d64ecc9afd0c0f8c8abdcf4f When processing the client supported groups and key shares extensions, the group selection is currently based on client preference. However, when building a HRR the preferred group is identified by calling tls1_get_supported_group(). If SSL_OP_CIPHER_SERVER_PREFERENCE is enabled, group selection will be based on server instead of client preference. This in turn can result in the server sending a HRR for a group that the client has already provided a key share for, violating the RFC. Avoid this issue by storing the client preferred group when processing the key share extension, then using this group when creating the HRR. Thanks to dzwdz for identifying and reporting the issue. ok beck@ tb@ from jsing@ This is errata/7.7/013_libssl.patch.sig 2025-09-30T12:54:18+00:00 tb 2025-09-30T12:54:18+00:00 urn:sha1:2f913441f29f1f81d45eb8d13b12bdfd75a57d70 cms_RecipientInfo_pwri_crypt: plug leak of kekalg cms: fix incorrect length check in kek_unwrap_key() An incorrect length check can result in a 4-byte overwrite and an 8-byte overread. From Stanislav Fort and Viktor Dukhovni via OpenSSL. CVE-2025-9230. ok jsing this is errata/7.7/010_libcrypto.patch.sig 2025-03-28T13:11:59+00:00 cvs2svn admin@example.com 2025-03-28T13:11:59+00:00 urn:sha1:9d824f57e18af2ec9fe3dab311be62b1e32eda9b 2025-03-28T13:11:57+00:00 tb 2025-03-28T13:11:57+00:00 urn:sha1:c3b500ab309a358fdb98b0f8e59b93f048d08b83 2025-03-28T12:34:19+00:00 tb 2025-03-28T12:34:19+00:00 urn:sha1:de7d7e36a30bf4dc5cdab5571ec7a8d8cb41e3ad 2025-03-28T12:17:16+00:00 tb 2025-03-28T12:17:16+00:00 urn:sha1:88db2f5852df3e02e139cc00bca104a07aa0a4ea 2025-03-28T12:13:03+00:00 tb 2025-03-28T12:13:03+00:00 urn:sha1:34d4647beddb60ec830124d4fc67ee4b51155edd 2025-03-25T11:54:34+00:00 tb 2025-03-25T11:54:34+00:00 urn:sha1:1246a392e49ed859fbba9a9b3352aee5dca07e54 The current documentation was clearly incorrect since a return of -1 from the methods is explicitly intercepted and translated to 0. schwarze and I both audited the tree and concluded that only 0 and 1 is possible. OpenSSL 3 broke this API contract and now has explicit return -1 in the convoluted 200-line maze this simple function has become with recent provider improvements. So add a small sentence hinting at that. Nobody will be surprised to read that with OpenSSL's characteristic penchant for needless inconsistency the return value checks in their tree are all over the place and sometimes incorrect. ok schwarze (with two tweaks) 2025-03-24T13:07:04+00:00 jsing 2025-03-24T13:07:04+00:00 urn:sha1:865465694bb9f7950a0710e8d7667d2540779602 EC_POINT_mul() has a complex multi-use interface - there are effectively three different ways it will behave, depending on which arguments are NULL. In the case where we compute g_scalar * generator + p_scalar * point, the mul_double_nonct() function pointer is called, however only g_scalar, p_scalar and point are passed - it is expected that the lower level implementation (in this case ec_wnaf_mul()) will use the generator from the group. Change mul_double_nonct(), ec_mul_double_nonct() and ec_wnaf_mul() so that they take scalar1, point1, scalar2 and point2. This removes all knowledge of g_scalar and the generator from the multiplication code, keeping it limited to EC_POINT_mul(). While here also consistently pass scalar then point, rather than a mix of scalar/point and point/scalar. ok tb@