[openssl/general-policies] 2de222: Drop VMS on Alpha and Itanium to unadopted, and on...
Branch: refs/heads/master Home: https://github.com/openssl/general-policies Commit: 2de222ffce6c32685988c7dac091c55415c96dea https://github.com/openssl/general-policies/commit/2de222ffce6c32685988c7dac091c55415c96dea Author: Richard Levitte Date: 2024-05-17 (Fri, 17 May 2024) Changed paths: M policy-supplemental/platforms.md Log Message: --- Drop VMS on Alpha and Itanium to unadopted, and on x86_64 to community Because of reasons, I'm dropping my dedication to that platform. Reviewed-by: Tim Hudson Reviewed-by: Matt Caswell Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/general-policies/pull/68) To unsubscribe from these emails, change your notification settings at https://github.com/openssl/general-policies/settings/notifications
[openssl/general-policies] 2dd1d8: Add Kurt's vote re RIMPEMD160 in OpenSSL 3.0
Branch: refs/heads/master Home: https://github.com/openssl/general-policies Commit: 2dd1d86c5c0e5c9996938449503f7f195b17d859 https://github.com/openssl/general-policies/commit/2dd1d86c5c0e5c9996938449503f7f195b17d859 Author: Richard Levitte Date: 2022-10-12 (Wed, 12 Oct 2022) Changed paths: M votes/vote-20221012-ripemd160-in-3.0-default-provider.txt Log Message: --- Add Kurt's vote re RIMPEMD160 in OpenSSL 3.0
[openssl/general-policies] 1d2377: Add Kurt's vote re selection and handling for SHA1...
Branch: refs/heads/master Home: https://github.com/openssl/general-policies Commit: 1d2377fbe6bdd673430923eeab56d3f8d59056ce https://github.com/openssl/general-policies/commit/1d2377fbe6bdd673430923eeab56d3f8d59056ce Author: Richard Levitte Date: 2022-10-12 (Wed, 12 Oct 2022) Changed paths: M votes/vote-20221012-handling-sha1-and-ripemd160.txt Log Message: --- Add Kurt's vote re selection and handling for SHA1 and RIMPEMD160
OMC VOTE: RIMPEMD160 in OpenSSL 3.0 default provider
Topic: Accept PR#19375 to add RIPEMD160 to the default provider for 3.0 subject to the normal review process Proposed by: Tim Public: yes Opened: 2022-10-12 Closed: 2022-10-12 Accepted: yes/no (for: 3, against: 0, abstained: 2, not voted: 1) Matt [+1] Mark [+1] Pauli [ 0] Tim[ 0] Richard[+1] Kurt [ ]
OMC VOTE: selection and handling for SHA1 and RIMPEMD160
Topic: Provider selection and handling for SHA1 and RIPEMD160 should be identical given the current understanding of algorithm specific security issues. Proposed by: Tim Public: yes Issue link: https://github.com/openssl/general-policies/issues/35 Opened: 2022-10-12 Closed: 2022-10-12 Accepted: yes/no (for: 5, against: 0, abstained: 0, not voted: 1) Matt [+1] Mark [+1] Pauli [+1] Tim[+1] Richard[+1] Kurt [ ]
[openssl/general-policies] 2e5697: Add vote re RIMPEMD160 in OpenSSL 3.0
Branch: refs/heads/master Home: https://github.com/openssl/general-policies Commit: 2e5697419515a0a25eb0820998123a9f325ea153 https://github.com/openssl/general-policies/commit/2e5697419515a0a25eb0820998123a9f325ea153 Author: Richard Levitte Date: 2022-10-12 (Wed, 12 Oct 2022) Changed paths: A votes/vote-20221012-ripemd160-in-3.0-default-provider.txt Log Message: --- Add vote re RIMPEMD160 in OpenSSL 3.0
[openssl/general-policies] b8b852: Add vote re selection and handling for SHA1 and RI...
Branch: refs/heads/master Home: https://github.com/openssl/general-policies Commit: b8b85215e2596a47b98ed37ba161ef9e566ef24c https://github.com/openssl/general-policies/commit/b8b85215e2596a47b98ed37ba161ef9e566ef24c Author: Richard Levitte Date: 2022-10-12 (Wed, 12 Oct 2022) Changed paths: A votes/vote-20221012-handling-sha1-and-ripemd160.txt Log Message: --- Add vote re selection and handling for SHA1 and RIMPEMD160
[openssl/general-policies] 918c86: Add vote re selection and handling for SHA1 and RI...
Branch: refs/heads/master Home: https://github.com/openssl/general-policies Commit: 918c86138a5d2495dc83e50781fc583cd4bd1992 https://github.com/openssl/general-policies/commit/918c86138a5d2495dc83e50781fc583cd4bd1992 Author: Richard Levitte Date: 2022-10-12 (Wed, 12 Oct 2022) Changed paths: A votes/vote-20221012-ripemd160-in-3.0-default-provider.txt Log Message: --- Add vote re selection and handling for SHA1 and RIMPEMD160
[openssl/general-policies] 59dbd9: Add vote re RIMPEMD160 in OpenSSL 3.0
Branch: refs/heads/master Home: https://github.com/openssl/general-policies Commit: 59dbd96730d772be7341b17db609735908becb6a https://github.com/openssl/general-policies/commit/59dbd96730d772be7341b17db609735908becb6a Author: Richard Levitte Date: 2022-10-12 (Wed, 12 Oct 2022) Changed paths: A votes/vote-20221012-ripemd160-in-3.0-default-provider.txt Log Message: --- Add vote re RIMPEMD160 in OpenSSL 3.0
[openssl/general-policies] 2b23a4: Move the platform policy to general-policies
Branch: refs/heads/master Home: https://github.com/openssl/general-policies Commit: 2b23a45c28c1357b2859325f08d98ffca004488f https://github.com/openssl/general-policies/commit/2b23a45c28c1357b2859325f08d98ffca004488f Author: Richard Levitte Date: 2022-10-12 (Wed, 12 Oct 2022) Changed paths: A policies/platform-policy.md A policy-supplemental/platforms.md Log Message: --- Move the platform policy to general-policies This is a copy of the current platform policy, found in the repository g...@github.com:openssl/web.git, policies/platformpolicy.md (or https://www.openssl.org/policies/platformpolicy.html), split up in a policy file and informational tables.
(Late) monthly report, May 2022
Apart from normal business, such as normal reviews, OMC business, OTC business, attending daily stand up meetings, attending OMC and OTC meetings, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Make configuration (and therefore builds) leaner - [not_yet_merged] Allow safer hooking of OPENSSL_cleanup in providers - [not_yet_merged] Stop using atexit() in libcrypto, reply on the app to call OPENSSL_cleanup() - [EXPERIMENTAL] Add an internal test to see what happens when reloading a shared object - Clear method store / query cache confusion - Generic Event Queue design - mdl: Don't enforce one space after list markers - Implement the generic event queue - [not_yet_merged] Implement the TRACE category ERR, to trace all added error records - Remove include/openssl/configuration.h from mandatory dependencies * Web: - Add a top level dirdata.yaml - Change news/changelog.md back to changelog.txt - Better dependencies for md->html rendering - Add better dependencies for generated files - Don't use $? when only the first prerequisite is to be used * Policies: ** General: - REVIEWED: Remove the double definitions of the OpenSSL Bylaws link. - REVIEWED: Add a process for minor policy edits - REVIEWED: Add security policy - REVIEWED: Add vote announcement to voting procedure ** Technical: - REVIEWED: coding-style.md: add various rules for writing C expressions - REVIEWED: Add a process for minor policy edits - REVIEWED: Add vote announcement to voting procedure - REVIEWED: coding-style.md: add various rules on spaces, lines, and comments - REVIEWED: Switch to C99 without the features that became optional in C11 * Sysadmin: ** Buildbot: - Integrate github.openssl.org - Add the VMS builders - Buildbot setup for w-vms8-ia64-1 and w-vms8-ia64-2 - Build all our public release branches - Set a 1 hour timeout on the VMS testing step - Take note of the 'basename' property when makeing the configuration command - Split builders (and schedulers) to become release branch specific ** Automation: - Add back the web setup for the openssl/openssl.git repo ** System configuration: - apache: add a TLS proxy in front of coverity - postfix: Add an alias for youtrack-machine - network: fix IPv6 on work.openssl.org - zenhub: Use 'zhe-config --update-tls' instead of 'zhe-config --reload' ** Other: - netmap.txt: Delineate what equipment belongs to Space.NET - Fixed an issue where github.openssl.org kept crashing under certain circumstances - Fixed an issue where pages on github.openssl.org showing 500 http error, with Github support assistance - Fixed Zenhub downtime, with Zenhub support assistance -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
(Late) monthly report, April 2022
Apart from normal business, such as normal reviews, OMC business, OTC business, attending daily stand up meetings, attending OMC and OTC meetings, normal system administration tasks, small fixes, etc., key activities this month: * Development: - [not yet merged] Make configuration (and therefore builds) leaner - Fix memleak in test/provider_test.c * Web: - Redirect /policies/codingstyle.html * Sysadmin: ** Buildbot: - Setup `w-debian11-intel` as buildbot worker ** Machinery: - log: Create a Debian 11 on arm64 guest - log: Create a FreeBSD 13 on x86_64 guest - log: set up the coverity guest system - Add management network on test.openssl.org ** System configuration: - Add a management network VPN - network: Fix configuration bugs - apache: Reconfigure www.openssl.org/docs as alias to /var/www/docs - apache: enable SSI on .html files in /var/www/docs - bind: assigned addresses to the coverity guest system - bind: Add a Google Workspace verification TXT record to openssl.org ** Other: - Create a Debian 11 on arm64 guest on new server - Set up the coverity guests system - Create a FreeBSD 13 on x86_64 guest on new server - Assisted in creating Google Workspace setup for OpenSSL - Add an admin HOWTO for adding management network VPN clients * Other: - Strawman manager policy -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
(Late) monthly report, March 2022
Apart from normal business, such as normal reviews, OMC business, OTC
business, attending daily stand up meetings, attending OMC and OTC
meetings, normal system administration tasks, small fixes, etc., key
activities this month:
* Development:
- VMS: move copy_argc to its own module and make it an aux source [backport
#8381 to 1.1.1]
- Rework dependencies between config files and build files
- Make ossltest engine use in test/recipes/20-test_dgst.t platform agnostic
- Make sure test/recipes/30-test_evp_extra.t has set up OPENSSL_ENGINES
- Fix OPENSSL_ENGINES in Configurations/descrip.mms.tmpl
- util/markdownlint.rb: Allow fenced code blocks
* Web:
- Treat the sitemap target separately
- Display the new policies on the site instead of linking to github
- separate docs building
* Policies:
** General:
- REVIEWED: Add additional glossary terms
- DISCUSSED: Extend the primary platforms support
** Technical:
- DISCUSSED: Documentation requirements
- DISCUSSED: Move technical policies from the website to the repository
- REVIEWED: Add links to glossary
* Infrastructure tools:
- Modify QueryApp internals, by renaming the role OMC to Data
- clacheck/clacheck.py: more python 3 adaptation
- clacheck: Ensure to read each patch line as a string
- Fix status.openssl.org for proper use of moved data
- Email the OMC, OTC and Committers groups when there's a status change
- Email the OMC, OTC and Committers re inactivity at end of last quarter
* Sysadmin:
** Automation:
- Fix generate-review-check-tables
- The "Initial web production" trigger build should depend on l_data, not
l_omc
- Build the site map last in the 'web' builder, using the 'sitemap' target
- Separate doc building from simple web building (adds a 'doc' builder)
- drop doc building in web builder
- Keep the web cleaner
- Add checkouts of {general,technical}-policies for the web builder
** CI:
- Add the configuration for ci-test, currently standalone
** Machinery:
- Set up management network
- log: Create a Debian 11 on x86_64 guest on work.openssl.org
- log: Create a Windows 10 on x86_64 guest on work.openssl.org
- log: Create a Ubuntu 20.04 on x86_64 guest on work.openssl.org
- log: Create a Debian 10 on x86_64 guest on work.openssl.org
- log: Add a development guest on work.openssl.org
- log: add management network to openssl-auth (auth.openssl.org)
** System configuration:
- iptables: Allow guests on the management network to reach each other
- apache: Reconfigure www.openssl.org/docs as alias to /var/www/docs
- apache: enable SSI on .html files in /var/www/docs
- bind: add a management network view
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
(Late) monthly report, December 2021
Apart from normal business, such as normal reviews, OMC business, OTC business, attending daily stand up meetings, attending OMC and OTC meetings, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Attended many QUIC design meetings - [WIP] APPS: break out a number of routines from apps/lib/apps.c, and clean up test/build.info - Fix EVP_PKEY_eq() to be possible to use with strictly private keys - Fix VMS installation - Fix faulty detail in BN_rand() manual - Make OSSL_provider_init() OPENSSL_EXPORT, not just extern - Add some CHANGES entries for 1.1.1m - Update NEWS for 1.1.1m - Reviewed the release of OpenSSL 3.0.1 and 1.1.1m * Web: - Drop the current roadmap - Convert scripts for Python 3 * Policies: - REVIEWED: Stable Release Updates Policy * Sysadmin: ** Machinery - Setup iLO of new server (work.openssl.org) with sysadmin users ** Git repositories - Create more github pre-receive hooks to replace those used in the gitolite setup: - no-merge-commits.sh - check-reviews.sh to replace VREF/UNREVIEWED/ - frozen.sh to replace VREF/FROZEN/ - Moved more repositories from gitolite to github.openssl.org ** System configuration - Disable TLSv1.0 and TLSv1.1 in our Apache config - Adapt gitweb to our new setup * Other: - Add authentication of incoming github requests in OMC tools clacheck/clacheck.py - Add functionality to extract all CLAs or CLAs for a specific group in OMC tools OpenSSL::Query, QueryApp -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
(Late) monthly report, December 2021
Apart from normal business, such as normal reviews, OMC business, OTC business, attending daily stand up meetings, attending OMC and OTC meetings, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Attended many QUIC design meetings - [WIP] APPS: break out a number of routines from apps/lib/apps.c, and clean up test/build.info - Fix EVP_PKEY_eq() to be possible to use with strictly private keys - Fix VMS installation - Fix faulty detail in BN_rand() manual - Make OSSL_provider_init() OPENSSL_EXPORT, not just extern - Add some CHANGES entries for 1.1.1m - Update NEWS for 1.1.1m - Reviewed the release of OpenSSL 3.0.1 and 1.1.1m * Web: - Drop the current roadmap - Convert scripts for Python 3 * Policies: - REVIEWED: Stable Release Updates Policy * Sysadmin: ** Machinery - Setup iLO of new server (work.openssl.org) with sysadmin users ** Git repositories - Create more github pre-receive hooks to replace those used in the gitolite setup: - no-merge-commits.sh - check-reviews.sh to replace VREF/UNREVIEWED/ - frozen.sh to replace VREF/FROZEN/ - Moved more repositories from gitolite to github.openssl.org ** System configuration - Disable TLSv1.0 and TLSv1.1 in our Apache config - Adapt gitweb to our new setup * Other: - Add authentication of incoming github requests in OMC tools clacheck/clacheck.py - Add functionality to extract all CLAs or CLAs for a specific group in OMC tools OpenSSL::Query, QueryApp -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Monthly report, February 2022
Apart from normal business, such as normal reviews, OMC business, OTC business, attending daily stand up meetings, attending OMC and OTC meetings, normal system administration tasks, small fixes, etc., key activities this month: * Development: - [not_yet_merged] Make configuration (and therefore builds) leaner - [not_yet_merged] Allow safer hooking of OPENSSL_cleanup in providers - [not_yet_merged] Stop using atexit() in libcrypto, reply on the app to call OPENSSL_cleanup() - [EXPERIMENTAL] Add an internal test to see what happens when reloading a shared object - Don't link test/ec_internal_test with libapps.a - Move e_os.h to include/internal - VMS: copy prologue/epilogue headers when header files are generated * Policies: ** General: - REVIEWED: Create a voting procedure - DISCUSSED: Add a policy change process - REVIEWED: Add a Support and Stability Policy - DISCUSSED: The next LTS release ** Technical: - REVIEWED: Branch Policy - REVIEWED: Add a Testing Policy - DISCUSSED: Make the voting policy match reality * Sysadmin: - Created an Epic with numerous sub-tasks (associated issues) for the build-up of a new CI. ** Machinery - Start logging initial setup of machines - Add a page on logging in as admin to the admin handbook - Add a HOWTO about adding an admin - On work.openssl.org, create a Debian 11 on x86_64 guest - On work.openssl.org, create a Debian 11 on ARM64 guest - Restored zenhub.openssl.org from outage ** Git repositories - Moved the main source repository from gitolite to github.openssl.org (this is the last one) * Other - Adapt status.openssl.org generator scripts for people and CLA databases being moved - Adapt QueryApp for people and CLA databases being moved - Adapt clacheck for people and CLA databases being moved -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
(Late) monthly report, January 2022
Apart from normal business, such as normal reviews, OMC business, OTC business, attending daily stand up meetings, attending OMC and OTC meetings, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Add signed bn2bin and bin2bn functions - We shouldn't use atexit() in our libraries (or modules, engines and providers alike) - Use ERR upcalls in legacy provider - Include the modules directory in openssl.pc - Looked at possible design for a generic comms API - Investigated the TAPS API (https://datatracker.ietf.org/doc/draft-ietf-taps-interface/) * Web: - Keep publishing manuals for 1.0.2 * Policies: - REVIEWED: Version policy - REVIEWED: Policy for accepting assembler optimisations - REVIEWED: Add Policy on API compatibility in minor releases - REVIEWED: Coding style policy - REVIEWED: Fix URL * Sysadmin: ** Machinery - Setup new server (work.openssl.org): - Installed Ubunto 20.04 - Installed libvirt+QEMU - Setup a default VM to clone from - Added issues for creating more VMs ** System configuration - Modified iptables on the old server (host.openssl.org) to not interfere with packets for work.openssl.org ** Other - Added HOWTOs on cloning pr creating a new guest - Updated hardware and network information - Updated our internal admin handbook -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
(Late) monthly report, November 2021
Apart from normal business, such as normal reviews, OMC business, OTC
business, attending daily stand up meetings, attending OMC and OTC
meetings, normal system administration tasks, small fixes, etc., key
activities this month:
* Development:
- Fix DER encoder implementations for output structures "EC" and "SM2"
- ERR: Add a missing common reason string
- Make OSSL_PARAM_BLD_push_BN{,_pad}() return an error on negative numbers
- DOC: Add a few previously documented functions [1.1.1]
- DOC: Add a few previously documented functions [3.0 and master]
- OSSL_PARAM_allocate_from_text() performs badly on edge cases for integers
- Fix OSSL_PARAM_allocate_from_text() to do sign extension
- TEST: Enable and fix test_bn2padded() in test/bntest.c
* Web:
- Make sure to create missing directories
* Policies:
- REVIEWED: Add a Design Process Policy
* Sysadmin:
** Git repositories
- Prepared gitolite for displaying messages of repositories moved to
github.openssl.org.
- Create some github pre-receive hooks to replace those used in the
gitolite setup:
- no-fixup-or-squash.sh to replace VREF/fixupsquash/
- no-unannotated-tags.shto replace VREF/OBJTYPE/commit/refs/tags/.*
- Moved some repositories from gitolite to github.openssl.org
** Automation
- Set up an automation buildbot to take over tasks that were done
with post-receive hooks in gitolite or cron jobs:
- make local mirrors of all github repos of interest
- make select local mirrors available through git://git.openssl.org/
and https://git.openssl.org/
- mirror push selected repositories to github.
- create snapshots (for https://ftp.openssl.org/snapshot/)
- generate OpenSSL's web pages
- generate OpenSSL's blog pages
** System configuration
- apache: modify the /blog alias for www.openssl.org
- Restored our mailman installation to Ubuntu packaging, and
upgraded it.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Monthly Status Report (October 2021)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Ensure we use the same provider as keymgmt where appropriate (PR openssl/openssl#16718) - EVP: Reverse the fetch logic in all pkey using functionality (PR openssl/openssl#16725) - Fix test/recipes/01-test_symbol_presence.t to allow for stripped libraries (PR openssl/openssl#16822) - Fix test/recipes/01-test_symbol_presence.t to disregard version info (PR openssl/openssl#16840) - [not_yet_nerged] Fix VMS installation (PR openssl/openssl#16842) - Fix lock leak in evp_keymgmt_util_export_to_provider() (PR openssl/openssl#16849) - Configurations/windows-makefile.tmpl: obj2bin(): use the resource file too (PR openssl/openssl#16875) * Web: - Update the details of VMS support (PR openssl/web#269) - bin/mk-latest: Treat post 1.x.x releases right (PR openssl/web#271) - Unify source archives (PR openssl/web#272) - Drop source/snapshot/README (PR openssl/web#275) * Internal: - do-release.pl: don't copy tarballs to /var/www/openssl/source any more -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Monthly Status Report (October 2021)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Ensure we use the same provider as keymgmt where appropriate (PR openssl/openssl#16718) - EVP: Reverse the fetch logic in all pkey using functionality (PR openssl/openssl#16725) - Fix test/recipes/01-test_symbol_presence.t to allow for stripped libraries (PR openssl/openssl#16822) - Fix test/recipes/01-test_symbol_presence.t to disregard version info (PR openssl/openssl#16840) - [not_yet_nerged] Fix VMS installation (PR openssl/openssl#16842) - Fix lock leak in evp_keymgmt_util_export_to_provider() (PR openssl/openssl#16849) - Configurations/windows-makefile.tmpl: obj2bin(): use the resource file too (PR openssl/openssl#16875) * Web: - Update the details of VMS support (PR openssl/web#269) - bin/mk-latest: Treat post 1.x.x releases right (PR openssl/web#271) - Unify source archives (PR openssl/web#272) - Drop source/snapshot/README (PR openssl/web#275) * Internal: - do-release.pl: don't copy tarballs to /var/www/openssl/source any more -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Monthly Status Report (September 2021)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Release OpenSSL 3.0.0 - OpenSSL::Ordinals::set_version() should only be given the short version (PR openssl/openssl#16556) - Fix the build file templates where uplink matters (PR openssl/openssl#16577) - Configurations/platform/Unix.pm: account for variants in sharedlib_simple() (PR openssl/openssl#16608) * Web: - Take into account the OpenSSL 3.0 branch (PR openssl/web#255) - Make the manpage sidebar generated from template (PR openssl/web#258) * Internal: * Sysadm: - Drop all traces of Request-Tracker - Drop run.openssl.org - Install a Mac Mini Intel and a buildbot worker on it - Install Zenhub instance -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Monthly Status Report (August 2021)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - util/add-depends.pl: Only add dependencies on existing or generated headers (PR openssl/openssl#16361) - util/add-depends.pl: Rebuild the build file after reconfiguration (PR openssl/openssl#16365) * Web: - Force the production of .inc files that are produced from the personel DB (CLOSED PR openssl/web#252) * Internal: - Major fixups of the FIPS buildbot master * Sysadm: - Rework our letsencrypt init and renewal scripts -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Monthly Status Report (July 2021)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Don't place any provider DER writer in libfips.a (PR openssl/openssl#15338) - DOC: clarify OPENSSL_API_COMPAT (PR openssl/openssl#15956) - TEST: Add testing of PVK and MSBLOB files to test_store (PR openssl/openssl#15980) - PROV & STORE: Don't decode keys in the 'file:' store loader (PR openssl/openssl#15981) - CRYPTO: Remove the check for built-in methods in the export_to function (PR openssl/openssl#15996) - ASN.1: Refuse to encode to DER if non-optional items are missing [3.0] (PR openssl/openssl#16036) - Avoid empty lines in nmake rule bodies (PR openssl/openssl#16048) - EVP: Add EVP_PKEY_get0_provider() and EVP_PKEY_CTX_get0_provider() (PR openssl/openssl#16063) - EVP: Move setting |keytype| in int_ctx_new() in the legacy section (PR openssl/openssl#16111) * Web: - Simplify the CDN purge (PR openssl/web#248) - Fix generation of community .inc files (PR openssl/web#250) * Internal: - Major work on the FIPS buildbot master * Sysadmin: - Decomissioned the Stockholm server - Wrote an Administrator Handbook for our staff -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Monthly Status Report (June 2021)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - STORE: Fix OSSL_STORE_open_ex() error reporting (PR openssl/openssl#15476) - Decoding PKCS#8: separate decoding of encrypted and unencrypted PKCS#8 (PR openssl/openssl#15498) - Configure: variable expand GENERATE values too (PR openssl/openssl#15554) - PROV: Specify correct signature sizes for ED25519 and ED448 signatures (PR openssl/openssl#15565) - DECODER & ENCODER: use property definitions instead of getting implementation parameters (PR openssl/openssl#15570) - util/mknum.pl: Allow unset ordinals in beta1-dev (PR openssl/openssl#15578) - test/recipes/80-test_cmp_http.t: Simplify test_cmp_http() (PR openssl/openssl#15580) - Deprecate EVP_CIPHER_impl_ctx_size and EVP_CIPHER_CTX_buf_noconst (PR openssl/openssl#15584) - Refactor XXX_do_all_provided() to behave like XXX_fetch() (PR openssl/openssl#15604) - FIPS: don't include crypto/passphrase.c in libfips.a (PR openssl/openssl#15615) - OpenSSL::Test.pm: Replace all uses of rel2abs() with abs_path() (PR openssl/openssl#15644) - APPS: Restore the possibility to combine -pubout with -text (PR openssl/openssl#15658) - STORE: Make OSSL_STORE_LOADER_fetch() consistent with all other fetch functions (PR openssl/openssl#15689) - Configure: Allow spaces around '=' in all build.info statements (PR openssl/openssl#15691) - Clean away remaining Travis related files (PR openssl/openssl#15692) - OpenSSL::Test: Treat SRCDATA directory specially, as it might not exist (PR openssl/openssl#15700) - OpenSSL::Test: If __cwd() is to create the directory, do it early (PR openssl/openssl#15701) - Windows Github CI: test in Windows 2016 as well (PR openssl/openssl#15709) - Building: Add necessary dependencies for linker scripts and .rc files (PR openssl/openssl#15717) - CORE: Move away the allocation of the temporary no_cache method store (PR openssl/openssl#15737) - CORE: Do a bit of cleanup of core fetching (PR openssl/openssl#15750) - VMS build: drop a spurious debug print (PR openssl/openssl#15758) - DSO: Fix the VMS DSO name converter to actually do something (PR openssl/openssl#15765) - TEST: Change 'catdir' to 'catfile' when dealing with files, in run_tests.pl (PR openssl/openssl#15767) - TEST: Make test/recipes/01-test_symbol_presence.t more platform agnostic (PR openssl/openssl#15771) - TEST: Display the correct shared library name (PR openssl/openssl#15776) - Make util/wrap.pl work better on VMS (PR openssl/openssl#15791) - test/recipes/80-test_cmp_http.t: Kill the mock server brutally (PR openssl/openssl#15797) - STORE: Fix OSSL_STORE_open_ex() error reporting, take 2 (PR openssl/openssl#15820) - TESTS: drop explicit quotes from empty command line arguments (PR openssl/openssl#15822) - Fix definition of ossl_intmax_t and ossl_uintmax_t (PR openssl/openssl#15825) - test/recipes/80-test_cmp_http.t: use app() rather than cmd() (PR openssl/openssl#15846) - Adapt shlibloadtest for VMS (PR openssl/openssl#15872) - ENCODER & DECODER: Allow en/decoders to have multiple names (PR openssl/openssl#15904) - Fix 'openssl req' to correctly use the algorithm from '-newkey algo:' (PR openssl/openssl#15912) - PROV: Have our PEM->DER decoder only recognise our PEM names (PR openssl/openssl#15930) - ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt (PR openssl/openssl#15933) - DECODER & ENCODER: Make sure to pass around the original selection bits (PR openssl/openssl#15934) * Web: - bin/mk-manpages3: install more than just HTML files (PR openssl/web#241) * Internal: - Worked on more details of the FIPS buildbot master -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Monthly Status Report (May 2021)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - FIPS module checksums: add scripts and Makefile rule (PR openssl/openssl#8871) - DOCS: Mention that libcrypto has helper functions for OSSL_PARAMs (PR openssl/openssl#15073) - APPS: Set a default passphrase UI for the "ec" command (PR openssl/openssl#15119) - Drop libimplementations.a (PR openssl/openssl#15171) - ASN1: Fix i2d_provided() return value (PR openssl/openssl#15277) - APPS: Make the cmp Mock server output the accept address and port (PR openssl/openssl#15281) - test/evp_extra_test2.c: Try EVP_PKEY_export() with a legacy RSA key (PR openssl/openssl#15292) - EVP: Modity EVP_PKEY_export() to handle legacy EVP_PKEYs (PR openssl/openssl#15293) - Rework how a build file (Makefile, ...) is produced (PR openssl/openssl#15310) - Adapt building OpenSSL 3.0 for VMS (PR openssl/openssl#15317) - Disable loader_attic on VMS (PR openssl/openssl#15320) - Small fixes for VMS (SIZE_MAX in a couple more places, and strtoumax / strtoimax) (PR openssl/openssl#15366) - VMS: don't use app_malloc() in apps/lib/vms_decc_argv.c (PR openssl/openssl#15368) - Configurations/descrip.mms.tmpl: rework the inclusion hacks (PR openssl/openssl#15369) - PROV: Relegate most of the FIPS provider code to libfips.a (PR openssl/openssl#15370) - DOCS: Fixups of the migration guide and the FIPS module manual (PR openssl/openssl#15377) - VMS: Fix run of generic generator programs in descrip.mms.tmpl (PR openssl/openssl#15397) - Fix 'openssl req' to be able to use provided keytypes (PR openssl/openssl#15400) - DOCS: Don't mention internal functions in public documentation (PR openssl/openssl#15422) - Rework how providers/fipsmodule.cnf is produced, and have a separate test/fipsmodule.cnf (PR openssl/openssl#15436) - util/fix-doc-nits: Fix link detection in collectnames() to be kinder (PR openssl/openssl#15450) - Rearrange the check of providers/fips.so dependencies (PR openssl/openssl#15514) - Add .asn1 dependencies for files generated from providers/common/der/*.in (PR openssl/openssl#15533) * Web: * Internal: - Worked on numerous details of the FIPS buildbot master * Sysadm: - Updated some configurations for newer Ubuntu installations (18.04 and 20.04) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: Accept Policy change process proposal
+1 On Mon, 01 Nov 2021 11:23:15 +0100, Tomas Mraz wrote: > > topic: Accept openssl/technical-policies PR#1 - the policy change > process proposal as of commit 3bccdf6. This will become an official OTC > policy. > > comment: This will implement the formal policy change process so we can > introduce and amend further policies as set by OTC via a public > process. > > Proposed by Tomáš Mráz > Public: yes > opened: 2021-11-01 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [ ] > Matt [ ] > Pauli [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: RSA public exponent validation in 3.0
0 On Tue, 10 Aug 2021 12:54:19 +0200, Matt Caswell wrote: > > topic: RSA public exponent validation in 3.0 for the default provider > should be > consistent with 1.1.1 > Comment: See issue #16255 for background > Proposed by Matt Caswell > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [ 0] > Matt [+1] > Pauli [ ] > Tim[+1] > Richard[ ] > Shane [+1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-0] > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1
-1 On Tue, 10 Aug 2021 12:53:23 +0200, Matt Caswell wrote: > > topic: Revert the commits merged from PR #16027 in 1.1.1 > Comment: Refer to issue #16266 for background > Proposed by Tomas Mraz > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [+1] > Matt [+1] > Pauli [ ] > Tim[-1] > Richard[ ] > Shane [-1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-1] > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1
On Wed, 11 Aug 2021 21:20:42 +0200, Kurt Roeckx wrote: > > There are a lot of things we accept in a certificate we shouldn't. PR #16027 isn't about what our code accepts, but about what it *produces*. At the very least, I see an interop problem, because when certain necessary structure values are missing, the DER (and PEM) encoding will be invalid for the declared content type. Just take the program from issue openssl/openssl#16026, but change the i2d_RSAPrivateKey() call to a PEM_write_RSAPrivateKey() call. This is a run again OpenSSL 1.1.1k (which is the version before this patch): : ; ./foo -BEGIN RSA PRIVATE KEY- MA0CAQACAwHiQAIDAQAB -END RSA PRIVATE KEY- Failed 'PEM_write_RSAPrivateKey(stdout, rsa, NULL, NULL, 0, NULL, NULL) <= 0' : levitte@lapdog:~/gitwrk/openssl.net/official/1.1.1 : ; ./foo | openssl asn1parse -i Failed 'PEM_write_RSAPrivateKey(stdout, rsa, NULL, NULL, 0, NULL, NULL) <= 0' 0:d=0 hl=2 l= 13 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :00 5:d=1 hl=2 l= 3 prim: INTEGER :01E240 10:d=1 hl=2 l= 3 prim: INTEGER :010001 That's a badly formatted RSAPrivateKey (it looks like a RSAPublicKey). Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Monthly Status Report (April 2021)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Key generation in OpenSSL 3.0-dev is inflexible compared to OpenSSL 1.1.1 (Issue openssl/openssl#14054) - [master] 'openssl enc' can't access ciphers that libcrypto doesn't know about (Issue openssl/openssl#14178) - [master] 'openssl dgst' can't access digests that libcrypto doesn't know about (Issue openssl/openssl#14179) - [not_yet_closed] [master] Allow the 'openssl enc' command to set a key length (Issue openssl/openssl#14180) - Resolve PKCS#7/CMS related backend hack (Issue openssl/openssl#14276) - Add OIDs among algorithm names + don't go via NIDs when fetching an algorithm from a ASN1_OBJECT (Issue openssl/openssl#14278) - Decoder implementations must be able to signal "please carry on" even if they can't decode the input (Issue openssl/openssl#14423) - Add OIDs among algorithm names + don't go via NIDs when fetching an algorithm from a ASN1_OBJECT (PR openssl/openssl#14498) - Add a description field to OSSL_ALGORITHM and use that as "long name" for provider implemented algos (Issue openssl/openssl#14514) - [not_yet_closed] Should we change the suffix of the resulting file name for modules on MacOS X, in 3.0? (Issue openssl/openssl#14602) - Add OSSL_ALGORITHM description field + API to use them (PR openssl/openssl#14656) - [not_yet_closed] Add more error recording in provider code (Issue openssl/openssl#14745) - Github workflows: re-implement a no-shared build (PR openssl/openssl#14753) - Refactor CPUID code, take 2 (PR openssl/openssl#14755) - test/recipes/02-test_errstr.t: Do not test negative system error codes (PR openssl/openssl#14779) - ENCODER & DECODER: Allow decoder implementations to specify "carry on" (PR openssl/openssl#14834) - ASN1: Ensure that d2i_ASN1_OBJECT() frees the strings on ASN1_OBJECT reuse (PR openssl/openssl#14938) - Makefile in master removes possible current release tarball (Issue openssl/openssl#14981) - Don't remove $(TARFILE) when cleaning (PR openssl/openssl#14985) - Windows bulding: Make dependency generation not quite as talkative (PR openssl/openssl#15006) - crypto/store/ossl_result.c: Better filtering of errors (PR openssl/openssl#15008) - STORE: Fix the repeated prompting of passphrase (PR openssl/openssl#15064) - STORE: Use the 'expect' param to limit the amount of decoders used (PR openssl/openssl#15066) - [not_yet_closed] Unix: link with libraries by direct file name (Issue openssl/openssl#15083) * Web: - bin/mk-latest: Make the adapation for the OpenSSL 3.0 version scheme work (PR openssl/web#232) - Makefile: Add FUTURESERIES, for series that have no final release yet (PR openssl/web#233) - Reorder the old source directory list in source/old/ (PR openssl/web#236) * Internal: - release-tools: Separate do-release.pl docs from mkrelease.pl docs (dir internal/tools) [9d9c86fe443afcb8a13a8ae40b91674a6afefcd3] * Sysadm: - Add new instruction on how to extend GHE storage space (dir admin/admin) [4d95719e6fef8bc50f20ad7dc0dfad89e0e9eb0d] -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Late Monthly Status Report (March 2021)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - [not_yet_merged] Configure: add -fkeep-inline-functions to --strict-warnings (PR openssl/openssl#8955) - [not_yet_closed] Propagate the no_store flag + consequences for evp_pkey_export_to_provider() (Issue openssl/openssl#14164) - [not_yet_closed] OpenSSL 3.0 currently doesn't build on OpenVMS, adaptation needed (Issue openssl/openssl#14247) - EVP_RAND should be renamed to OSSL_RAND (Issue openssl/openssl#14297) - Provider side encoders and decoders need to stop using EVP_PKEY (Issue openssl/openssl#14306) - Stop using EVP_PKEY in encoders and decoders (PR openssl/openssl#14314) - Make 'tests' depend on a generated 'providers/fipsmodule.cnf' (PR openssl/openssl#14320) - Fix threading issues in crypto/provider_core.c (PR openssl/openssl#14354) - test/threadstest.c: Add a test to load providers concurrently (PR openssl/openssl#14372) - DOCS: Fix provider-mac.pod and the docs of our implementations (PR openssl/openssl#14380) - DOCS: Document OSSL_STORE_INFO_PUBKEY in doc/man3/OSSL_STORE_INFO.pod (PR openssl/openssl#14415) - Undo passing of params to provider side init/derive/instantiate (PR openssl/openssl#14435) - [not_yet_closed] Introduce EVP level fetchable sigalg functionality (Issue openssl/openssl#14467) - PROV: use EVP_CIPHER_CTX_set_params() rather than EVP_CIPHER_CTX_ctrl() (PR openssl/openssl#14484) - TEST: Cleanup test recipes (PR openssl/openssl#14505) - [not_yet_closed] Introduce EVP level fetchable PRF functionality (Issue openssl/openssl#14543) - Configure: check all DEPEND values against GENERATE, not just .h files (PR openssl/openssl#14598) - Fix a missing rand -> ossl_rand rename (PR openssl/openssl#14609) - ASN1: Reset the content dump flag after dumping (PR openssl/openssl#14627) - RSA-PSS: When printing parameters, always print the trailerfield ASN.1 value (PR openssl/openssl#14676) - [not_yet_closed] test/pkits-test.pl not suitable for current OpenSSL (Issue openssl/openssl#14709) - Unix build file template: symlink "simple" to "full" shlib selectively (PR openssl/openssl#14726) - Re-implement ANSI C building with a Github workflow (PR openssl/openssl#14729) * Web: - REVIEWED: Update newsflash for the 3.0 alpha13 release (PR openssl/web#223 by mattcaswell) - Complete the transition changelog.txt -> changelog.md (PR openssl/web#224) * Other: - Started over with buildbot master development / configuration / setup -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Late Monthly Status Report (February 2021)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - [not_yet_closed] Lack of verbosity in verbose test display (environment variables) (Issue openssl/openssl#12024) - EVP: use evp_pkey_copy_downgraded() in EVP_PKEY_copy_parameters() (PR openssl/openssl#13341) - ERR: drop function code macro generation (PR openssl/openssl#13392) - Remove the old DEPRECATEDIN macros (PR openssl/openssl#13461) - appveyor.yml: clarify conditions for building the plain configuration (PR openssl/openssl#13537) - VMS documentation fixes [1.1.1] (PR openssl/openssl#13834) - VMS documentation fixes [master] (PR openssl/openssl#13835) - EVP: Implement data-driven translation between known ctrl and OSSL_PARAMs (PR openssl/openssl#13913) - EVP: Don't find standard EVP_PKEY_METHODs automatically (PR openssl/openssl#13973) - [WIP] X509: Refactor X509_PUBKEY processing to include provider side keys (PR openssl/openssl#13994) - PROV: Add SM2 encoders and decoders, as well as support functionality (PR openssl/openssl#14028) - PROV: Fix encoding of MDWithRSAEncryption signature AlgorithmID (PR openssl/openssl#14030) - Allow the sshkdf type to be passed as a single character (PR openssl/openssl#14035) - CORE & PROV: clean away OSSL_FUNC_mac_size() (PR openssl/openssl#14048) - TEST: Add an algorithm ID tester for libcrypto vs provider (PR openssl/openssl#14049) - Dirty count for provider native keys + cleanup (PR openssl/openssl#14056) - DOCS: Update the internal documentation on EVP_PKEY. (PR openssl/openssl#14059) - dev/release.sh: Fix typo (PR openssl/openssl#14061) - DOCS: Remove the "global" dependency on writing .pod files from .pod.in (PR openssl/openssl#14067) - configdata.pm: Better display of enabled/disabled options (PR openssl/openssl#14081) - Configuration: ensure that 'no-tests' works correctly (PR openssl/openssl#14082) - Use ERR_R_*_LIB instead of ERR_LIB_* as reason code for sub-libraries (PR openssl/openssl#14152) - OSSL_PARAM: Correct the assumptions on the UTF8 string length (PR openssl/openssl#14168) - Fix backward incompatibility revolving around OSSL_HTTP_REQ_CTX_sendreq_d2i() (PR openssl/openssl#14196) - TEST: Add missing initialization (PR openssl/openssl#14204) - [not_yet_closed] It would be nice to have internal libcrypto routines to query the defined algorithm properies (Issue openssl/openssl#14217) - DECODER: Use the data structure from the last decoder to select the next (PR openssl/openssl#14233) - Generate doc/build.info with 'make update' rather than on the fly (PR openssl/openssl#14269) - util/perl/OpenSSL/config.pm: Fix determine_compiler_settings() (PR openssl/openssl#14270) - X509: Refactor X509_PUBKEY processing to include provider side keys (PR openssl/openssl#14281) - Make i2d_PublicKey() work with provider side EC EVP_PKEYs (PR openssl/openssl#14291) - Makefile: Only update doc/build.info when there's an actual change (PR openssl/openssl#14309) * Web: - Fix bin/mk-manpages3 to handle spurious & in the description (PR openssl/web#214) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Late Monthly Status Report (December 2020)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - [not_yet_closed] [tentative] ECDH provider side implementation doesn't care about peer key parameters, should it? (Issue openssl/openssl#11491) - DISCUSSED: Is OAEP working as expected? (Issue openssl/openssl#12981 by mattcaswell) - Add EVP_PKEY_get_group_name and use that in libssl instead of evp_pkey_get_EC_KEY_curve_nid() (PR openssl/openssl#13436) - Switch deprecation method (PR openssl/openssl#13460) - TEST: Add a simple module loader, and test the FIPS module with it (PR openssl/openssl#13507) - APPS: Check that all apps really consume all command line arguments (Issue openssl/openssl#13527) - Does EVP_ENCODER_CTX_new_by_EVP_PKEY() need an explicit library context? (Issue openssl/openssl#13544) - ENCODER: Don't pass libctx to OSSL_ENCODER_CTX_new_by_EVP_PKEY() (PR openssl/openssl#13545) - PEM: Add a more generic way to implement PEM _ex functions for libctx (PR openssl/openssl#13547) - Make algorithm specific EVP_PKEY_CTX setters and getters more available (Issue openssl/openssl#13550) - APPS: Add OSSL_STORE loader for engine keys, and use it (PR openssl/openssl#13570) - DOCS: Update OSSL_DECODER_CTX_new_by_EVP_PKEY.pod to match declarations (PR openssl/openssl#13581) - Make DH & EC EVP_PKEY_CTX parameter ctrls / setters more available (PR openssl/openssl#13589) - CHANGES: Move misplaced change item (PR openssl/openssl#13605) - DSA: Make DSA_bits() and DSA_size() check that there are key parameters (PR openssl/openssl#13611) - providers/common/der/build.info: Improve checks of disabled algos (PR openssl/openssl#13626) - DOCS: Improve documentation of the EVP_PKEY type (PR openssl/openssl#13629) - Deprecate DSA harder (cont. from #13187) (PR openssl/openssl#13638) - PROV: Add MSBLOB and PVK encoders (PR openssl/openssl#13645) - PEM: Unlock MSBLOB and PVK functions from 'no-dsa' and 'no-rc4' (PR openssl/openssl#13648) - [URGENT] Fix sanitizer build (PR openssl/openssl#13661) - Building: Fix the library file names for MSVC builds to include multilib (PR openssl/openssl#13670) - Drop OPENSSL_NO_RSA everywhere (PR openssl/openssl#13700) - GitHub CI: Add 'check-update' and 'check-docs' (PR openssl/openssl#13701) - TEST: Fix test/endecode_test.c for 'no-legacy' (PR openssl/openssl#13705) - Fix 'no-deprecated' (PR openssl/openssl#13706) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Late Monthly Status Report (November 2020)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - [WIP] APPS: Refactoring dsaparam and dhparam (PR openssl/openssl#12072) - EVP: Adapt EVP_PKEY2PKCS8() to better handle provider-native keys (PR openssl/openssl#12995) - Deprecate RSA harder (PR openssl/openssl#13096) - Add new provider encoders implementations for more output standards, take 2 (PR openssl/openssl#13167) - util/fix-deprecation: DEPRECATEDIN conversion util for public headers (PR openssl/openssl#13239) - Simplify and clarify doc/internal/man7/deprecation.pod (PR openssl/openssl#13240) - test/endecoder_legacy_test.c: new test for legacy comparison (PR openssl/openssl#13262) - test/recipes/90-test_shlibload.t: Skip when address sanitizer enabled (PR openssl/openssl#13281) - Cleanup error reporting in crypto/ (PR openssl/openssl#13318) - Cleanup error reporting providers (PR openssl/openssl#13319) - Really deprecate the old NAMEerr() macros (PR openssl/openssl#13320) - Fix test/recipes/80-test_ca.t to skip_all properly in a subtest (PR openssl/openssl#13331) - EVP: Have all EVP_PKEY check functions export to provider if possible (PR openssl/openssl#13334) - Small passphrase reading fixes (PR openssl/openssl#13346) - ERR: deprecate all old ERR_load_ and stop producing new ones (PR openssl/openssl#13390) - Fix SUPPORT.md for better readability (PR openssl/openssl#13398) - DOC: Fixup the description of the -x509_strict option (PR openssl/openssl#13412) - util/mkrc.pl: Make sure FILEVERSION and PRODUCTVERSION have four numbers (PR openssl/openssl#13415) - util/find-doc-nits: check podchecker() return value (PR openssl/openssl#13416) - DOC: Fix example in OSSL_PARAM_int.pod (PR openssl/openssl#13426) - SSL: Change SSLerr() to ERR_raise() (PR openssl/openssl#13450) - TEST: Make our test data binary (PR openssl/openssl#13477) - DOC: Add note on how to terminate an OSSL_PARAM array (PR openssl/openssl#13478) - APPS: Guard use of IPv6 functions and constants with a check of AF_INET6 (PR openssl/openssl#13484) - ERR: Restore the similarity of ERR_print_error_cb() and ERR_error_string_n() (PR openssl/openssl#13510) - APPS: Modify the way apps/cmp.c silences the UI_METHOD when -batch is given (PR openssl/openssl#13512) - EVP_PKEY & DSA: Make DSA EVP_PKEY_CTX parameter ctrls / setters more available (PR openssl/openssl#13530) - TEST: Fix path length in test/ossl_store_test.c (PR openssl/openssl#13546) - RSA: correct digestinfo_ripemd160_der[] (PR openssl/openssl#13562) * Web: - REVIEWED: Update newsflash for alpha 8 release (PR openssl/web#206 by mattcaswell) - REVIEWED: Update newsflash for new release (PR openssl/web#208 by mattcaswell) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: Reject PR#14759
0 On Tue, 20 Apr 2021 12:23:56 +0200, Nicola Tuveri wrote: > > Following up on > https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html we had > a > discussion on this during last week OTC meeting, and opened a vote limited > exclusively to the > matter of rejecting PR#14759. > > We lost the record of the votes collected during the call, so opening it > officially today with a > clean slate. > > > topic: Reject PR#14759 > Proposed by Nicola Tuveri > Public: yes > opened: 2021-04-20 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely
0 On Tue, 23 Feb 2021 11:21:41 +0100, Tomas Mraz wrote: > > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. > > comment: The padding mode and the related functions (which are already > deprecated in the current master branch) is useless outside of SSLv2 > support. We do not support SSLv2 and we do not expect anybody using > OpenSSL 3.0 to try to support SSLv2 by calling those functions. > > Proposed by Tomas Mraz. > > public: yes > opened: 2021-02-23 > > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
OMC VOTE result: No release of 1.1.1j next week
As of regular cadence, 1.1.1j would have been released next week. However, seeing that we released 1.1.1i last week, the OMC made a quick vote. Vote: As an exception to the regular cadence, we will not release 1.1.1j on 22 December For: 5, Against: 0, Abstain: 0, Didn’t vote yet: 2 The vote passes. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OSSL_PARAM behaviour for unknown keys
.pod current says: > > > Keys that a I or I doesn't recognise should > > > simply be ignored. That in itself isn't an error. > > > > > > The intention of that seems to be that you just pass all the data > > > you have, and that it takes data it needs. So you can pass it data > > > that it doesn't need because it's only used in case some other > parameter > > > has some specific value. For example, depending on the DRBG mode > > > (HMAC, CTR, HASH) you have different parameters, and you can just > > > pass all the parameters for all the modes. > > > > > > I think for behaviour for a setter is not something that we want, > > > it makes it complicated for applications to check that it will > > > behave properly. I think that in general, if the applications > > > wants to set something and you don't understand it, you should > > > return an error. This is about future proofing the API. For > > > instance, a new version supports a new mode to work in and that > > > needs a new parameter. If it's build against a version that knows > > > about it, but then runs against a version that doesn't know about > > > it, everything will appear to work, but be broken. If we return > > > an error, it will be clear that it's not supported. > > > > > > An alternative method of working is that the application first > > > needs to query that it's supported. And only if it's supported > > > it should call the function. But we don't have an API to query for > > > that. You might be able to ask for which keys you can set, but it > > > doesn't cover which values you can set. I hope we at least return > > > an error for a known key with an unknown value. But it's my > > > understanding that we currently don't always return all supported > > > keys, and that the supported keys can depend on one of the set > > > parameters. > > > > > > I suggest that we change the return value to indicate that all > > > parameters have been used or not. For instance return 1 in case > > > all used, return 2 in case not all used. > > > > > > > > From my GOST implementor's experience, the provider can get a lot of > > parameters. > > Some of them are supported, some of them are not. > > > > The particular provider is the only subsystem that knows which > parameters > > are supported and which are necessary for the operations. > > > > So the caller can provide some unsupported parameters, some supported > and > > some totally wrong for the provider. > > These are the cases that must be distinguishable on the caller side. > > If I understand you correctly, what you're saying is that it's > sometimes ok to ignore some parameters. For instance, if you try > to create an RSA object, and you pass it CRT parameters, and the > implementation doesn't do anything with them, it can ignore them > if it wants to. > > I would say that the provider should know what those parameters > mean, so that it's not an "unknown key", it just ignores them, > at which points it can say that it understands all the parameters. > > Some might argue that they don't want to use something that > doesn't make use of the CRT parameters, but then they probably > shouldn't be using that provider to begin with. > > > After that the provided EVP object should be either in a consistent > state > > or not, assuming the upcoming operation. > > The object should always be in a consistent state. I would prefer > that in case of failure the object is not created (or modified). > Which brings us to some other open points about the API we have. We > should not introduce new APIs where you can modify the state of the > object, so it can not be in a non-consistent state. It's much more > simple to get things correct in that case. But as long as we have > to support old APIs where it can be modified, the prefered > consistent state is to not mofify the object on error. Some APIs make > this very hard, so the other acceptable state is that you can free > the object. With an API that doesn't allow modification, either > you get a complete object, or you get no object. > > Kurt > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: Keeping API compatibility with missing public key
+1 On Fri, 04 Dec 2020 13:45:07 +0100, Tomas Mraz wrote: > > Vote background > --- > > The vote on relaxing the conceptual model in regards to required public > component for EVP_PKEY has passed with the following text: > > For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: > * relax the conceptual model to allow private keys to exist without > public components; > * all implementations apart from EC require the public component to be > present; > * relax implementation for EC key management to allow private keys that > do not contain public keys and > * our decoders unconditionally generate the public key (where > possible). > > However since then the issue 13506 [1] was reported. > > During OTC meeting we concluded that we might need to relax also other > public key algorithm implementations to allow private keys without > public component. > > Vote > > > topic: For 3.0 EVP_PKEY keys all algorithm implementations that were usable >with 1.1.1 EVP_PKEY API or low level APIs without public component must >stay usable. > >This overrules the > * all implementations apart from EC require the public component to > be present; >part of the vote closed on 2020-11-17. > > Proposed by Tomas Mraz > Public: yes > opened: 2020-12-04 > > Tomas Mraz > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: Fixing missing failure exit status is a bug fix
+1 On Mon, 30 Nov 2020 13:03:15 +0100, Nicola Tuveri wrote: > > Vote background > --- > > This follows up on a [previous proposal] that was abandoned in favor of > an OMC vote on the behavior change introduced in [PR#13359]. > Within today's OTC meeting this was further discussed with the attending > members that also sit in the OMC. > > The suggestion was to improve the separation of the OTC and OMC domains > here, by having a more generic OTC vote to qualify as bug fixes the > changes to let any OpenSSL app return an (early) failure exit status > when a called function fails. > > The idea is that, if we agree on this technical definition, then no OMC > vote to allow a behavior change in the apps would be required in > general, unless, on a case-by-case basis, the "OMC hold" process is > invoked for whatever reason on the specific bug fix, triggering the > usual OMC decision process. > > [previous proposal]: > <https://www.mail-archive.com/openssl-project@openssl.org/msg02241.html> > [PR#13359]: <https://github.com/openssl/openssl/pull/13359> > > > > Vote text > - > > topic: In the context of the OpenSSL apps, the OTC qualifies as bug >fixes the changes to return a failure exit status when a called >function fails with an unhandled return value. >Even when these bug fixes change the apps behavior triggering >early exits (compared to previous versions of the apps), as bug >fixes, they do not qualify as behavior changes that require an >explicit OMC approval. > Proposed by Nicola Tuveri > Public: yes > opened: 2020-11-30 > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: EVP_PKEY private/public key components
This is what I read:
- the key in p256_invalid.pem is invalid in other ways than merely the
lack of the public key in the file.
(the public key is *not* lacking in run-time in this example, since
d2i_ECPrivateKey() autogenerates it, which happens before it's
checked or used)
- you confirmed that the public key isn't really relevant for this
problem, apart from triggering a check error that's really emanating
from some other invalid data.
This does not, however, demonstrate what happens when the EVP_PKEY
holds an EC_KEY that lacks a public key, because in run-time, it in
fact does *not* lack a public key. So while that's an interesting
discussion, it doesn't really demonstrate your concerns about this
vote.
BTW, regarding checking, I did a bit of an experiment; I removed the
autogeneration of the public key from d2i_ECPrivateKey(), and relaxed
ec_key_simple_check_key() so it only checks eckey->pub_key if it's
actually present... and of course removeed a few eckey->pub_key NULL
checks along the way. EVP_PKEY_check still fails, but now with the
detailed error "wrong order", which sounds perfectly reasonable
considering your description, so it looks to me like the invalidity
of the key can be caught either way.
From a contents point of view, p256_invalid.pem is actually perfectly
valid, or you would have gotten ASN1 errors when trying to load it.
Cheers,
Richard
P.S. I'd like to pause the debate at this point... it looks like
we're getting back into locked positions, and I'm not keen on
continuing under those conditions.
On Mon, 16 Nov 2020 19:06:51 +0100,
Nicola Tuveri wrote:
>
> The issue with that key is that the secret scalar `k` is equal to `n`
> (where `n` is the order of the generator point `G`), while for EC keys
> the validity range is `1 <= k < n`.
>
> If the scalar `k` is equal to `n`, it means that the associated pubkey
> is `k*G` = `n*G` = `0*G mod n` = `P_infinity`.
> The pubkey generation in the `d2i_` routines is correctly being
> triggered because the PEM file I generated only includes the secret
> scalar: if we did not catch the point at infinity validating the
> public component we would reach the private component validity checks
> and we would trigger the private scalar range check.
>
> The infinite loop happens not because of the public component (that as
> we know is not touched during signature generation) but because the
> secret scalar is effectively congruent to `0 mod n` in the computation
> to generate the `s` value of the signature.
>
> I would not classify this as a bug, but as a programmer error: the
> user is using an invalid key (this has nothing to do with the "keypair
> assumption", literally `k` is a value out of range according to the
> relevant spec).
> Input key material should be validated: if not at each run (for
> performance reason), once after it has been serialized to disk and
> protected with proper measures to ensure the validated key material is
> not tampered with (or leaked).
>
>
> If we consider this a bug, or a potential DoS attack vector, we would
> likely fix it by running validation of the `EVP_PKEY` object on load
> (and with some caching mechanism to validate keys created manually via
> `EC_KEY` objects): this would once again reveal that the use pattern
> in #12612 was invalid to begin with, as the validity checks were
> enforcing the "keypair assumption" in 1.1.1 and previous versions.
>
>
> Nicola
>
> On Mon, Nov 16, 2020 at 7:44 PM Richard Levitte wrote:
> >
> > Er, Nicola, I'm unsure how that endless loop has anything to do with
> > the presence or the absence of a public key, as it happens in
> > ossl_ecdsa_sign_sig(), which doesn't even look at the public key, at
> > all.
> >
> > Your check does say that the key you have there is invalid, but that
> > would rather be because from that private key and group, it seems that
> > d2i_ECPrivateKey() generates a public key with Z == 0, which is indeed
> > infinity as I understand it. You can see that for yourself with a
> > breakpoint at d2i_ECPrivateKey(), step down to about line 1042
> > (current OpenSSL_1_1_1-stable, btw), and simply look:
> >
> > (gdb) p *ret->pub_key
> > $16 = {meth = 0x77f0dc00 , curve_name = 415, X =
> > 0x556450f0,
> > Y = 0x55645090, Z = 0x556450b0, Z_is_one = 0}
> > (gdb) p *ret->pub_key->Z
> > $17 = {d = 0x55641170, top = 0, dmax = 4, neg = 0, flags = 1}
> > (gdb) p *ret->pub_key->X
> > $18 = {d = 0x55641ec0, top = 4, dmax = 4, neg = 0, flags = 1}
> > (gdb) p *ret->pub_key->Y
> > $19 = {d = 0x55641e40, top = 4, dmax = 4, neg = 0, flags = 1}
> >
> > (
Re: OTC VOTE: EVP_PKEY private/public key components
Er, Nicola, I'm unsure how that endless loop has anything to do with
the presence or the absence of a public key, as it happens in
ossl_ecdsa_sign_sig(), which doesn't even look at the public key, at
all.
Your check does say that the key you have there is invalid, but that
would rather be because from that private key and group, it seems that
d2i_ECPrivateKey() generates a public key with Z == 0, which is indeed
infinity as I understand it. You can see that for yourself with a
breakpoint at d2i_ECPrivateKey(), step down to about line 1042
(current OpenSSL_1_1_1-stable, btw), and simply look:
(gdb) p *ret->pub_key
$16 = {meth = 0x77f0dc00 , curve_name = 415, X = 0x556450f0,
Y = 0x55645090, Z = 0x556450b0, Z_is_one = 0}
(gdb) p *ret->pub_key->Z
$17 = {d = 0x55641170, top = 0, dmax = 4, neg = 0, flags = 1}
(gdb) p *ret->pub_key->X
$18 = {d = 0x55641ec0, top = 4, dmax = 4, neg = 0, flags = 1}
(gdb) p *ret->pub_key->Y
$19 = {d = 0x55641e40, top = 4, dmax = 4, neg = 0, flags = 1}
(ret->pub_key->Z->top == 0, that's a bignum zero)
That still has no impact on the infinite loop as far as I can see, but
that may be an indication that something else is wrong with that
private key.
It's also possible that if there are conditions that may cause an
infinite loop, that is a bug in itself that needs a fix.
I believe this loop is due for a raised issue, unless there already is
one.
(if there isn't, I wonder why)
Cheers,
Richard
On Thu, 12 Nov 2020 11:33:13 +0100,
Nicola Tuveri wrote:
>
> > Nonsense. Each iteration involves a new PRN, which by definition you
> > cannot predict.
>
> ~~~sh
> ; which openssl; openssl version
> /usr/bin/openssl
> OpenSSL 1.1.1f 31 Mar 2020
> ; cat > /tmp/p256_invalid.pem
> -BEGIN PRIVATE KEY-
> MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCD/AP//
> vOb6racXnoTzucrC/GMlUQ==
> -END PRIVATE KEY-
> ; openssl pkey -check -text -noout -in /tmp/p256_invalid.pem
> Key is invalid
> Detailed error: point at infinity
> Private-Key: (256 bit)
> priv:
> ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:
> ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:63:
> 25:51
> pub:
> 00
> ASN1 OID: prime256v1
> NIST CURVE: P-256
> ; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32
> ; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash
> -out /tmp/sig.der
> # here is the infinite loop
> ~~~
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: EVP_PKEY private/public key components
On Wed, 11 Nov 2020 23:34:53 +0100, Nicola Tuveri wrote: > > By design the consistency checks and validation checks are omitted > unless these functions are called, and there is no > EVP_PKEY_private_check. Just a small point, this is in master: $ grep private_check include/openssl/evp.h int EVP_PKEY_private_check(EVP_PKEY_CTX *ctx); Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: EVP_PKEY private/public key components
On Sun, 15 Nov 2020 22:36:54 +0100,
Kurt Roeckx wrote:
>
> On Tue, Nov 03, 2020 at 12:11:27PM +, Matt Caswell wrote:
> >
> > The proposal discussed was that while relaxing the conceptual model,
> > most of the existing implementations would still require both. The EC
> > implementation would be relaxed however. This essentially gives largely
> > compatible behaviour between 1.1.1 and 3.0.
> >
> > The vote text is as follows:
> >
> > topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> > * relax the conceptual model to allow private keys to exist without public
> > components;
> > * all implementations apart from EC require the public component to be
> > present;
> > * relax implementation for EC key management to allow private keys that
> > do not
> > contain public keys and
> > * our decoders unconditionally generate the public key (where possible).
> >
> > Proposed by Matt Caswell
> > Public: yes
> > opened: 2020-11-03
> > closed: 2020-mm-dd
> > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T)
>
> So I think being compatible with what 1.1.1 does is important.
> And what the text does is try to make rules for what 1.1.1 does,
> but as far as I understand it, it's not really describing what
> 1.1.1 does.
>
> I think we should just fix the regressions. For fixing the
> regressions we don't need a vote.
The vote includes exactly the items needed to fix the regression. In
reality, this is already mostly fixed, because all our new decoders
will reconstruct the public key exactly the same way the old backends
did, because they all call the exact same d2i_{TYPE}PrivateKey()
internally, which do the actual work.
The only actual work remaining to fix the regression is to relax the
EC keymgmt import function to accept receiving a private key without
the public key. It doesn't actually need to regenerate a public key
either. That will allow a construct similar to the one that was
reported in #12612.
In practical terms, that doesn't sound like very hard work.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Late Monthly Status Report (September 2020)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - [WIP] EVP: retrieve EVP_CIPHER constants in the evp_cipher_from_dispatch() (PR openssl/openssl#11980) - [not_yet_merged] [WIP] APPS: Refactoring dsaparam and dhparam (PR openssl/openssl#12072) - DOC: Modify one example in EVP_PKEY_fromdata(3) (PR openssl/openssl#12389) - CORE: Implement unconditional provider autoactivation (PR openssl/openssl#12497) - [reviewed] Add SM2 key management (PR openssl/openssl#12536 by InfoHunter) - OSSL_STORE: Move 'file:' scheme loader to provider (PR openssl/openssl#12587) - dev/release.sh: Rework to be smoother (PR openssl/openssl#12614) - Building: Build Unix static libraries a limited number of object files at a time (PR openssl/openssl#12706) - PEM: Make PEM_write_bio_PrivateKey_traditional() handle provider-native keys (PR openssl/openssl#12738) - EVP: Preserve the EVP_PKEY id in a few more spots (PR openssl/openssl#12785) - EVP: Add support for delayed EVP_PKEY operation parameters (PR openssl/openssl#12789) - TEST: skip POSIX errcode zero in test/recipes/02-test_errstr.t (PR openssl/openssl#12799) - [reviewed] NonStop port updates for 3.0.0. (PR openssl/openssl#12800 by rsbeckerca) - ENCODER: Refactor provider implementations, and some cleanup (PR openssl/openssl#12803) - Diverse build.info: Adjust paths (PR openssl/openssl#12816) - STORE: Fix OSSL_STORE_attach() to check |ui_method| before use (PR openssl/openssl#12831) - OSSL_DECODER 'decode' function must never be NULL. (PR openssl/openssl#12849) - EC: Reimplement EVP_PKEY_CTX_set_ec_param_enc() to support providers (PR openssl/openssl#12853) - EVP: Centralise fetching error reporting (PR openssl/openssl#12857) - ENCODER: Refactor the OSSL_ENCODER API to be more like OSSL_DECODER (PR openssl/openssl#12873) - OpenSSL::ParseC: recognise inline function bodies (PR openssl/openssl#12882) - util/mkerr.h: Restore header file rename (PR openssl/openssl#12910) - EVP: Enforce that EVP_PKEY_set_alias_type() only works with legacy keys (PR openssl/openssl#12920) - DOC: POD syntax fixes in doc/man1/openssl-cmp.pod.in (PR openssl/openssl#12924) - Streamline/Rationalize HPE NonStop Configuration (PR openssl/openssl#12933) - Configurations/unix-Makefile.tmpl: make cleanup kinder (PR openssl/openssl#12939) - Hide ECX_KEY again (PR openssl/openssl#12956) - Configuration: Make it possible to have an argument file (PR openssl/openssl#12960) - Build: Make NonStop shared libraries only export selected symbols (PR openssl/openssl#12962) - STORE: Clear a couple of TODOs that were there for the sake of SM2 (PR openssl/openssl#12986) - Configure: handle undefined shared_target. (PR openssl/openssl#13031) * Web: - [reviewed] Add a new section to the Coding Style about argument ordering (PR openssl/web#194 by mattcaswell) - [reviewed] Add a new section to the Coding Style about extending existing functions (PR openssl/web#195 by mattcaswell) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Monthly Status Report (October 2020)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Configuration: add initial NonStop values in OpenSSL::config (PR openssl/openssl#12973) - EVP: Take care of locks when downgrading an EVP_PKEY (PR openssl/openssl#12978) - [not_yet_merged] EVP: Adapt EVP_PKEY2PKCS8() to better handle provider-native keys (PR openssl/openssl#12995) - Make a build file target to install the FIPS module installation config file (PR openssl/openssl#13032) - EVP: use evp_pkey_ctx_is_legacy() to find what implementation to use (PR openssl/openssl#13043) - APPS: Reduce deprecation warning suppression - ENGINE (PR openssl/openssl#13044) - DECODER: Handle abstract object data type (PR openssl/openssl#13060) - DECODER: Allow precise result type for OSSL_DECODER_CTX_new_by_EVP_PKEY() (PR openssl/openssl#13061) - Refactor deprecation macros (PR openssl/openssl#13074) - Modify util/mknum.pl to drop new symbols that don't exist any more (PR openssl/openssl#13092) - Fix diverse ERR code conflicts (PR openssl/openssl#13093) - ENCODER / DECODER: Add functions to encode/decode to/from a buffer (PR openssl/openssl#13094) - [not_yet_merged] Add new provider encoders implementations for more output standards (PR openssl/openssl#13095, openssl/openssl#13167) - [not_yet_merged] Deprecate RSA harder (PR openssl/openssl#13096) - DH: stop setting the private key length arbitrarily (PR openssl/openssl#13140) - TEST: fix small logic error in test/evp_pkey_provided_test.c (PR openssl/openssl#13146) - TEST: modify tconversion.pl for forensics (PR openssl/openssl#13147) - ENCODER & DECODER: set params on all encoder/decoder instances, unconditionally (PR openssl/openssl#13156) - dev/release.sh: improve instruction for pushing the tag (PR openssl/openssl#13159) - DH: make the private key length importable / exportable (PR openssl/openssl#13166) - Add easy to digest selector macros for EVP_PKEYs (PR openssl/openssl#13189) - Work around Windows ftell() bug as per Microsoft engineering's suggestion (PR openssl/openssl#13190) - APPS: Implement load_keyparams() to load key parameters (PR openssl/openssl#13191) - Unexport internal MSBLOB and PVK functions (PR openssl/openssl#13196) - configdata.pm.in: Make a HERE document stricter. (PR openssl/openssl#13225) - APPS: Remove the format argument where it's not used (PR openssl/openssl#13236) - [not_yet_merged] util/fix-deprecation: DEPRECATEDIN conversion util for public headers (PR openssl/openssl#13239) - [not_yet_merged] Simplify and clarify doc/internal/man7/deprecation.pod (PR openssl/openssl#13240) - [not_yet_merged] Add new provider decoders implementations for more input standards (PR openssl/openssl#13248) - [not_yet_merged] test/endecoder_legacy_test.c: new test for legacy comparison (PR openssl/openssl#13262) - test/recipes/15-test_gendh.t: don't try DER params (PR openssl/openssl#13266) - [not_yet_merged] test/recipes/90-test_shlibload.t: Skip when address sanitizer enabled (PR openssl/openssl#13281) - [not_yet_published] Adapt OpenSSL 3.0 for VMS -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Late Monthly Status Report (August 2020)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - OSSL_STORE for providers, take 2 (PR openssl/openssl#12512) - PROV: Make the DER to KEY deserializer decode parameters too (PR openssl/openssl#12569) - DESERIALIZER: Fix EVP_PKEY construction by export (PR openssl/openssl#12571) - Add MSBLOB and PVK deserializers (PR openssl/openssl#12574, openssl/openssl#12601) - RSA: Be less strict on PSS parameters when exporting to provider (PR openssl/openssl#12583) - EVP: Fix the returned value for ASN1_PKEY_CTRL_DEFAULT_MD_NID (PR openssl/openssl#12586) - EVP: Have evp_pkey_cmp_any() detect if export wasn't possible (PR openssl/openssl#12610) - Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODER / OSSL_DECODER (PR openssl/openssl#12659, openssl/openssl#12660) - X509: Add d2i_PUBKEY_ex(), which take a libctx and propq (PR openssl/openssl#12671) - TEST: separate out NIST ECC tests from non-NIST (PR openssl/openssl#12672) - PEM: Add more library context aware PEM readers (PR openssl/openssl#12673) - RSA: Fix rsa_todata() to only add params for existing data (PR openssl/openssl#12676) - PROV: Fix EC OSSL_FUNC_keymgmt_match() to work in the FIPS provider (PR openssl/openssl#12677) - PROV: Fix DSA and DH private key serializers (PR openssl/openssl#12679) - crypto/x509/v3_utl.c: Fix IPv6 output in ipaddr_to_asc() (PR openssl/openssl#12696) - TEST: Fix CMP tests so they load keys in the current library context (PR openssl/openssl#12705) - Fix PEM_write_bio_PrivateKey_traditional() to not output PKCS#8 (PR openssl/openssl#12728) - [1.1.1] Fix PEM_write_bio_PrivateKey_traditional() to not output PKCS#8 (PR openssl/openssl#12729) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Late Monthly Status Report (July 2020)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - [closed in favor of #12512] WIP: OSSL_STORE for providers (PR openssl/openssl#9389) - Configure: Check source and build dir equality a little more thoroughly (PR openssl/openssl#12337) - util/perl/OpenSSL/config.pm: move misplaced Windows and VMS entries (PR openssl/openssl#12339) - Refactor ERR codes (PRs openssl/openssl#12314, openssl/openssl#12343) - Configure: fix handling of build.info attributes with value (PR openssl/openssl#12344) - Configuration and build: Fix solaris tags (PR openssl/openssl#12360) - CORE: perform post-condition in algorithm_do_this() under all circumstances (PR openssl/openssl#12365) - DOC: install documentation without execution permissions. (PR openssl/openssl#12373) - Makefile template: fix incorrect treatment of produced document files (PR openssl/openssl#12374) - BN: Check endianness in run-time, in BN_native2bn() and BN_bn2nativepad() (PR openssl/openssl#12390) - OSSL_DESERIALIZER: New API for provider based deserializers (PR openssl/openssl#12410) - util/find-doc-nits: read full declarations as one line in name_synopsis() (PR openssl/openssl#12452) - Fix typo for SSL_get_peer_certificate() (PR openssl/openssl#12468) - PROV: Move bio_prov.c from libcommon.a to libfips.a / libnonfips.a (PR openssl/openssl#12486) - PROV: Add a DER to RSA-PSS deserializer implementation (PR openssl/openssl#12492) - util/find-doc-nits: Relax check of function declarations in name_synopsis() (PR openssl/openssl#12494) * System Administration: - Performed operating system upgrade on our main machine * Other: - Performed the release of OpenSSL 3.0.0 alpha5 -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Late Monthly Status Report (June 2020)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Incorporate system guessing in Configure (PR openssl/openssl#11230) - PEM: Make PKCS8 serializing functions aware of OSSL_SERIALIZERs (PR openssl/openssl#11855) - APPS: Make it possible to load_cert() from stdin again (PR openssl/openssl#11873) - CORE: make sure activated fallback providers stay activated (PR openssl/openssl#11926) - APPS: Create a library context in the main app, and pass it to commands (PR openssl/openssl#11982) - APPS: Drop interactive mode in the 'openssl' program (PR openssl/openssl#12023) - EVP: Let EVP_PKEY_gen() initialize ctx->keygen_info (PR openssl/openssl#12048) - TESTUTIL: Separate TAP output and other output by BIO filter (PR openssl/openssl#12057) - util/find-doc-nits: Do not read "missing" files when -u is given (PR openssl/openssl#12125) - EVP: allow empty strings to EVP_Decode* functions (PR openssl/openssl#12144) - DOCS: Add documentation for EVP_PKEY_CTX_set_rsa_pss_keygen_mgf1_md_name() (PR openssl/openssl#12188) - Build: Remove faulty DES assembler spec (PR openssl/openssl#12203) - CORE: Add OPENSSL_CTX_set0_default(), to set a default library context (PR openssl/openssl#12228) - INSTALL.md: Restore $ as command prompt indicator (PR openssl/openssl#12257) - apps/openssl: Fix buffer-overflow for command with no arguments (PR openssl/openssl#12259) - apps/openssl: clean-up of unused fallback code (PR openssl/openssl#12295) * Other: - Performed the transition from travis-ci.org to travis-ci.com. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Meaning of no-xxx option
I'm afraid your interpretation isn't quite correct. The no-xxx options remove the actual code for the thing being disabled, but it doesn't turn off access to a compatible implementation. For example, you could conceptually have an ENGINE with an alternative DSA implementation that's perfectly usable through the EVP interface (keys will have to be loaded through that same engine, though), regardless of any no-dsa configuration. This is also reflect in the apps. Yes, the key type specific commands like 'openssl dsa' are disabled, but that's because in 1.1.1, they use the lower level APIs and can simply not build at all if the calls they depend on aren't there. However, if you look at apps/*pkey*.c, you will find very few uses of OPENSSL_NO_ macros. 1.1.1 only guards engine calls with OPENSSL_NO_ENGINE... master has some OPENSSL_NO_EC guards, for reasons I'm currently unaware of, I assume some kind of special case that should really be removed. So I guess this comes down to what's currently being done, where commands like 'openssl dsa' starts to use EVP functionality, and thereby become *more* available than before. If that's good or bad, only time will tell... In summary, the time where no-xxx truly meant that the algorithm xxx is completely unavailable is long gone. The addition of ENGINEs changed that... not immediately, but as soon as the ENGINE API got functionality to help implement EVP_PKEY_METHODs and EVP_PKEY_ASN1_METHODs. Cheers, Richard On Sun, 18 Oct 2020 09:33:11 +0200, Kurt Roeckx wrote: > > Hi, > > It seems that we might start to interprete the no-xxx options > differently. In 1.1.1 it would completly disable the feature in > libcrypto, the apps and libssl. It seems that now the > interpretation changed to just disable the support for it in the > provider. You might load a different provider that does support > it, and so the apps and libssl can use it then. > > My interpretation was always that we want to completly disable the > feature, for instance because we don't want to use it at all or we > want to reduce the size of the binries. > > > Kurt > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Additional things for deprecation
Hmmm, are we going to start marking types for deprecation? I would advise against it on a general level, 'cause that's likely to cause an implosion. See for example marking ENGINE for deprecation, i.e. this: diff --git a/include/openssl/types.h b/include/openssl/types.h index ee024cef29..4e73c0dc0d 100644 --- a/include/openssl/types.h +++ b/include/openssl/types.h @@ -172,7 +172,9 @@ typedef struct ossl_init_settings_st OPENSSL_INIT_SETTINGS; typedef struct ui_st UI; typedef struct ui_method_st UI_METHOD; -typedef struct engine_st ENGINE; +# ifndef OPENSSL_NO_DEPRECATED_3_0 +OSSL_DEPRECATEDIN_3_0 typedef struct engine_st ENGINE; +# endif typedef struct ssl_st SSL; typedef struct ssl_ctx_st SSL_CTX; Try that and see your build become... interesting. Cheers, Richard On Tue, 13 Oct 2020 11:40:37 +0200, Tim Hudson wrote: > > In a 3.0 context, EVP_PKEY_ASN1_METHOD and all the associated functions > should be marked > deprecated in my view. > > Tim. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality
+1 On Thu, 08 Oct 2020 16:27:18 +0200, Matt Caswell wrote: > > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim[ ] > Richard[ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: VOTE: Technical Items still to be done
+1 As for "EVP is the recommended API", I hope that everyone understands this to be for crypto functionality (hash functions, cipher functions, EVP_PKEY functions, MAC functions, KDF functions), not *everything*. On Thu, 08 Oct 2020 16:47:18 +0200, Matt Caswell wrote: > > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. >- Anything that isn’t available must be put to an OTC vote to exclude. >- The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. >- Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). >- Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. >- There might be some others. >- Review for exceptions. >- The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) >- Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) >- Need a list of things we know are not present - including things we > have > removed. >- We need to have mapping tables for various d2i/i2d functions. >- We need to have a mapping table from “old names” for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to >the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim[ ] > Richard[ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch
Cancel that, wrong vote. For this, 0 On Tue, 13 Oct 2020 10:09:12 +0200, Richard Levitte wrote: > > +1 > > On Fri, 09 Oct 2020 14:02:29 +0200, > Tomas Mraz wrote: > > > > topic: The PR #11359 (Allow to continue with further checks on > > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > > As the change is borderline on bug fix/behaviour change OTC needs > > to decide whether it is acceptable for 1.1.1 branch. > > Proposed by Tomas Mraz > > Public: yes > > opened: 2020-10-09 > > closed: 2020-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > > > Matt [ ] > > Mark [ ] > > Pauli [ ] > > Viktor [ ] > > Tim[ ] > > Richard[ ] > > Shane [ ] > > Tomas [+1] > > Kurt [ ] > > Matthias [ ] > > Nicola [ ] > > > > -- > > Tomáš Mráz > > No matter how far down the wrong road you've gone, turn back. > > Turkish proverb > > [You'll know whether the road is wrong if you carefully listen to your > > conscience.] > > > > > -- > Richard Levitte levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released
+1 On Fri, 09 Oct 2020 14:00:00 +0200, Nicola Tuveri wrote: > > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 >and until 3.0 beta1 is released, in lieu of the weekly "developer >meetings". > Proposed by Nicola Tuveri > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim[ ] > Richard[ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch
+1 On Fri, 09 Oct 2020 14:02:29 +0200, Tomas Mraz wrote: > > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim[ ] > Richard[ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Vote proposal: Private keys can exist independently of public keys
On Wed, 07 Oct 2020 21:25:57 +0200, Nicola Tuveri wrote: > > On Wed, 7 Oct 2020 at 20:45, Richard Levitte wrote: > > > > I'm as culpable as anyone re pushing the "convention" that an EVP_PKEY > > with a private key should have a public key. I was incorrect. > > Sure, my example was not about pointing fingers! I didn't try to imply that you did, just wanted to own up to my part in it. > It's just to give recent data points on how the documentation written > in 2006 is probably not something as stale as one can think, because > until recently we were leveraging that assumption at least in some > sections of the lower layers. Were we? Not in the operations... however, this picked my curiousity and got me to look at this from a different angle. See, it seems that what we're mostly disputing is the behaviour of the keymgmt import function, which is related to loading keys from file, among others. When loading private keys from PEM files in 1.1.1, we do rely entirely on the related i2d functions, which do implement the ASN.1 structures quite failthfully, so our basis of deciding what's ok or not is at influenced by associated standardised ASN.1 key formats. I did just now look up the ASN.1 key format for ECC keys, and it seems that our EC keymgmt ends up violating that standard. I've commented further on that in the issue: https://github.com/openssl/openssl/issues/12612#issuecomment-705162303 > I think the lack of NULL checks is intertwined with this problem as > long as in some code that does access the public key component we > ensured we dereference without making the NULL check because of the > assumption. Looking again at #12612, I don't quite see where the conclusion that we're missning NULL checks comes from. EVP_DigestSignInit() fails, quite correctly, because it's been given a key that couldn't be (automatically) exported to a provider, because the keymgmt import refused it for the lack of a public key. Had the import accepted this key material, the signature operation would have worked with no issues whatsoever as far as I can see, because it doesn't use the public key. And the code we use for the actual computation does a NULL check on the private key. I can't see that the issue was a lack of NULL check, rather the contrary in this case. > The problem I see with spot checking rather than writing a > comprehensive suite of tests, is that given our wide API surface and > the compromises taken in the transition from non-opaque stack > allocated objects in 1.0.2 to opaque objects in 1.1.1+, we might have > non-obvious places where dereferencing the public key without checking > for NULL can bite us. The current ECC private keys embedded in test/recipes/30-test_evp_data/evppkey_ecc.txt (both in 1.1.1 and 3.0) currently all have a public key present. It should be possible to change some of them to have the public key removed, or add test stanza with private keys that don't have the public part. I agree that we should add such stanzas, and probably test them on 1.1.1 as well as on 3.0, to ensure that we don't have the dormant bug that you fear that we might have. Mind you, there's another possible answer for ECC keys. If you look at crypto/dh/dh_ameth.c and crypto/dsa/dsa_ameth.c, and look up dh_priv_decode() and dsa_priv_decode()... well, you only need to read the comment, really. See, a PKCS#8 structure with a DH or DSA key only has the private key. No public key whatsoever, so DSA and DH keys can be said to be in the same situation as ECC keys... it's just that our legacy code to decode such PKCS#8 structures will recalculate the public key from the private key and the parameters. I'm not terribly keen on that idea, and specially not on the idea to possibly have to reproduce it in the provided decoders, which means that we're putting that pressure on other provider authors as well. However, if that suites everyone better, we have a precedent. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Vote proposal: Private keys can exist independently of public keys
I'm as culpable as anyone re pushing the "convention" that an EVP_PKEY
with a private key should have a public key. I was incorrect.
Regarding avoiding NULL checks, that's actually a separate story,
evem though it overlaps conveniently. There was the idea, for a
while, that we should avoid NULL checks everywhere (unless it's valid
input), and indeed make it a programmer error if they happened to pass
NULL where they shouldn't.
One can see that as an hard assertion, and that has indeed produced
crashes that uncovered bugs we might otherwise have missed. The tide
has changed though, and it seem like the fashion du jour is to check
NULLs and error with an ERR_R_PASSED_NULL_PARAMETER. I'm not sure
that we've made an actual hard decision in either direction, though.
However, I'm not sure where the NULL check problem comes in.
Operations that don't use the public key parts don't need to look at
the public key parts, so a NULL check there is simply not necessary.
Cheers,
Richard
On Wed, 07 Oct 2020 19:20:45 +0200,
Nicola Tuveri wrote:
>
> Re; "enforcement"
>
> My impression is that there is no such enforcement, because the
> project has (had?) a stance on "avoid NULL checks" and "consider
> things that break our documented assumptions as programmer errors".
>
> The natural result of these two principles may very well be the
> deliberate reason why "enforcement" cannot be found and we might
> perceive documentation written in 2006 as not current.
>
> I can say that in the past 4 years within PR I authored or
> co-authored, even before becoming a Committer, I can recall reviews
> requesting to amend the code to avoid NULL checks on the public key
> component because it is our convention that an EVP_PKEY with key
> material is either a public key or a key pair.
>
>
> Nicola
>
> On Wed, 7 Oct 2020 at 19:52, Richard Levitte wrote:
> >
> > As far as I can tell, the existing "enforcement" is in the algorithm
> > implementations. I had a look through the following files in OpenSSL
> > 1.1.1:
> >
> > crypto/rsa/rsa_ossl.c
> > crypto/dsa/dsa_ossl.c
> > crypto/dh/dh_key.c
> > crypto/ec/ecdsa_ossl.c
> > crypto/ec/ecdh_ossl.c
> >
> > I first had a look at the key computing functions in dh_key.c and
> > ecdh_ossl.c, because I was told that the public key is looked at
> > there. This turns out to be somewhat false; they do look at a public
> > key, the public key of the peer key that they get passed, which isn't
> > quite the same. However, when it comes to the DH or EC_KEY they work
> > with, only the private half is looked at,
> >
> > Looking at dsa_ossl.c and ecdsa_ossl.c, I can see that the signing
> > functions do NOT look a |pub_key|, and the verification functions do
> > NOT look at |priv_key|. This seems perfectly normal to me.
> >
> > Similarly, the signing functions in rsa_ossl.c do NOT seem to look at
> > |d|, and the verification functions do NOT seem to look at |e|.
> >
> > I took a moment to search through the corresponding *meth.c files to
> > see if I could quickly grep for some kind of check, and found none.
> > Mind you, that was a *quick* grep, someone more thorough might want to
> > confirm or contradict.
> >
> > So, having looked through that code, my sense is that the "enforcement"
> > that's talked about is non-existent, or at least very unclear, and I
> > suspect that if there is some sort of "enforcement" at that level,
> > it's more accidental than by design...
> >
> > I'm not sure what to make of the documentation from 2006. Considering
> > the level of involvement there was from diverse people (2006 wasn't
> > exactly the most eventful time), there's a possibility that it was a
> > precaution ("don't touch that can of worms!") than a firm decision.
> >
> > Cheers,
> > Richard
> >
> > On Wed, 07 Oct 2020 17:34:25 +0200,
> > Nicola Tuveri wrote:
> > >
> > > I believe the current formulation is slightly concealing part of the
> > > problem.
> > >
> > > The way I see it, the intention if the vote passes is to do more than
> > > stated:
> > > 1. change the long-documented assumption
> > > 2. fix "regressions" in 3.0 limited to things that worked in a certain
> > > way in 1.1.1 (and maybe before), _despite_ the documented assumption
> > > 3. test all existing functions that access the public key component of
> > > `EVP_PKEY` (or lower level) objects to ensure they don't rely on the
> > > long-documented assumption
> > > 4. fix all the pl
Re: Vote proposal: Private keys can exist independently of public keys
t; scenario where this has not historically been enforced, and it now is in > > the current 3.0 code causing a regression. > > > > There are differences of opinion on how this should be handled. Some > > have the opinion that we should change the model so that we explicitly > > allow private keys to exists without the public components. Others feel > > that we should continue with the old model. > > > > It seems we need a vote to decide this. Here is my proposed vote text: > > > > We should change the 3.0 code to explicitly allow private components to > > exist in keys without the public components also being present. > > > > Feedback please on the proposed vote text. > > > > Matt > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Vote proposal: Private keys can exist independently of public keys
preceded by a NULL pointer > > check or guaranteed non-NULL from any caller. > > To change the long documented assumption, we commit to improve test > > coverage of all public functions directly or indirectly triggering > > potential access to public key components, to prevent the risk of user > > facing crashes. > > > Nicola > > > > > On Wed, 7 Oct 2020 at 14:29, Matt Caswell wrote: > > > > Issue #12612 exposes a problem with how we handle keys that contain > > private components but not public components. > > > > There is a widespread assumption in the code that keys with private > > components must have public components. There is text in our public > > documentation that states this (and that text dates back to 2006). > > > > OTOH, the code has not always enforced this. Issue #12612 describes a > > scenario where this has not historically been enforced, and it now is in > > the current 3.0 code causing a regression. > > > > There are differences of opinion on how this should be handled. Some > > have the opinion that we should change the model so that we explicitly > > allow private keys to exists without the public components. Others feel > > that we should continue with the old model. > > > > It seems we need a vote to decide this. Here is my proposed vote text: > > > > We should change the 3.0 code to explicitly allow private components to > > exist in keys without the public components also being present. > > > > Feedback please on the proposed vote text. > > > > Matt > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: VOTE: OTC meeting will be called for next Tuesday
+1 On Wed, 30 Sep 2020 15:57:34 +0200, Dr. Matthias St. Pierre wrote: > > The following vote has been proposed and voted on at the vF2F today: > > topic: OTC meeting will be called for next Tuesday > > It has been closed immediately by Tim, the verdict is > > accepted: yes (for: 7, against: 0, abstained: 0, not voted: 4) > > (Note: the OTC meeting will be held in place of the weekly OpenSSL 3.0 > Planning > meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a separate > invitation to the OTC list.) > > Matthias > > > topic: OTC meeting will be called for next Tuesday (2020-10-06) > Proposed by Matthias St. Pierre > Public: yes > opened: 2020-09-30 > closed: 2020-09-30 > accepted: yes (for: 7, against: 0, abstained: 0, not voted: 4) > > Matt [+1] > Mark [ ] > Pauli [+1] > Viktor [ ] > Tim[+1] > Richard[+1] > Shane [+1] > Tomas [ ] > Kurt [ ] > Matthias [+1] > Nicola [+1] > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Proposal for a libcrypto module style guide / policy
The code style proposal that we had before didn't fare well and was
deemed incomplete or contradictory. Still, we need something for a
more overall view on how we should design an new API as well as how we
should treat existing APIs.
Here's a proposal for something that I/we hope have grasped all the
diverse feedback that's come our way and can become a good enough
guide.
I currently have it as a separate file, and not committed anywhere,
because I wasn't sure where it should end up, and need ideas.
Something to be noted is the current coding style policy doesn't
have a natural space for higher level items such as whole APIs (as
opposed to individual functions) or modules. My proposal would be to
have a separate document for API / module design (the name of the
attached text is a possible name).
Ideas, thoughts, constructive criticism, acclamations, etc welcome.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
OpenSSL modules
===
A module in the sense described here is a part of OpenSSL functionality, in
particular in libcrypto, not a dynamically loadable module.
A module is recognised by its upper case beginning of public function names.
For example, "RAND_bytes" is a function in the RAND module.
In the rest of this text, '{NAME}' is used to represent the module name.
For working with entire modules, we have three cases to consider:
1. Existing modules
2. New modules
3. Function arguments in new modules
[
note: there are core "modules" as well, which aren't quite the same.
CRYPTO and OSSL_PROVIDER come to mind.
]
Existing modules
>From time to time it is necessary to extend an existing module with new
functions. To make such functions consistent with the API of that module,
look at similar or related functions in the same module, otherwise follow
the general rules for adding functions in a new module as described below.
New modules
===
OpenSSL modules may have different levels of complexity:
1. Simple
2. Class
3. Class, dynamic
Simple
--
The absolutely simplest don't have an associated type, and simply have
functions of this form:
rettype {NAME}_do_something([args])
Otherwise, still fairly simple are those with an associated type that has
the same name as the module, but nothing more:
{NAME} *{NAME}_new([args])
rettype {NAME}_get_something({NAME} *,[args])
rettype {NAME}_set_something({NAME} *,[args])
rettype {NAME}_do_something({NAME} *,[args])
void {NAME}_free({NAME} *)
Class
-
Somewhat more complex modules have multiple backend implementations, much
like C++ classes have virtual methods. For those, there are two types,
{NAME} and {NAME}_METHOD, where {NAME} holds execution data, while
{NAME}_METHOD holds function pointers to a backend implementation.
Such modules should use the following pattern:
{NAME} *{NAME}_new({NAME}_METHOD *, [args])
rettype {NAME}_get_something({NAME} *,[args])
rettype {NAME}_set_something({NAME} *,[args])
rettype {NAME}_do_something({NAME} *,[args])
void {NAME}_free({NAME} *)
Class, dynamic
--
Some more complex modules are also dynamic, in that they get their
implementation from diverse places, and referring to those implementations
isn't as simple as using a method structure pointer directly. It's often
more suitable that the constructor finds the method structure implicitly,
from a given implementation name or an object that can be used to derive a
suitable name from.
The constructor for such a module typically relies on a factory pool, such
as OPENSSL_CTX (OPENSSL_CTX is a bag of diverse core library things, and is
generally seen as the libcrypto library state. With constructors, it is
used in the role of a factory pool).
The constructor pattern should look like this:
{NAME} *{NAME}_new(OPENSSL_CTX *libctx, const char *name, [args])
{NAME} *{NAME}_new(OPENSSL_CTX *libctx, OBJTYPE *object, [args])
The first variant is a straightforward construct by name, the second would
rather derive the name from another related type.
The rest of such a module's API should like as in "Class" above.
Function arguments in new modules
=
For all of the above patterns, the remaining argument list (seen as '[args]'
above) should be put into order of importance. Deciding the relative
importance of arguments is necessarily somewhat subjective, but the
following guideline ordering of the arguments should be considered:
1) additional context arguments
If multiple contexts are necessary then they should be in order of most
general to most specific. In some cases (typically with an OPENSSL_CTX),
a context may be NULL to indicate a default context should be used.
[ This should be *very* rare ]
2) Data transfer parameters (these are parameters used to convert or copy
some sort of input
Re: Status of the remaining beta1 PRs
On Fri, 18 Sep 2020 17:24:59 +0200, Matt Caswell wrote: > > 1 PR which is in a state of "we really need to do something about this": > [WIP, Parked] EVP: Adapt EVP_PKEY_set_alias_type() for provider-native > EVP_PKEYs > https://github.com/openssl/openssl/pull/12675 > Since this affects a public API we probably really do need to figure out > what to do with the EVP_PKEY_set_alias_type() There's a counter PR now: #12920 -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: 3.0 beta 1 milestone
I've found what's going wrong there, and I agree that it needs to be fixed ASAP, although I don't view it per se as a beta 1 blocker. Either way, a fix is coming up. Cheers, Richard On Thu, 17 Sep 2020 19:21:50 +0200, Dmitry Belyavsky wrote: > > > Dear Matt, > > I think #12891 is a significant problem. I'd suggest fixing it before beta1 > or at least discuss > it. > > Many thanks! > > On Thu, Sep 17, 2020 at 3:48 PM Matt Caswell wrote: > > There's been quite a number of PRs added to the 3.0 beta 1 milestone. > > Within the PRs there are a couple of bug fixes: > > https://github.com/openssl/openssl/pull/12884 > https://github.com/openssl/openssl/pull/12874 > > IMO these would be really nice to get into beta 1, but they should not > be considered blockers for it (i.e. if they didn't go in, it shouldn't > stop us from releasing beta 1). > > There are also some nice-to-have items: > > https://github.com/openssl/openssl/pull/12777 > https://github.com/openssl/openssl/pull/12771 > https://github.com/openssl/openssl/pull/12726 > https://github.com/openssl/openssl/pull/12669 > https://github.com/openssl/openssl/pull/12072 > > Again - these are nice-to-have, and if they happen to get merged in time > for beta 1 then great. Otherwise, they should wait for 3.1 (possibly > things which are just cleanup/minor refactoring could still be done > within the beta period). So, IMO, these should not be considered > blockers either. > > So - this leads me to the question - what is the milestone for? Does it > means these things *must* go in before we can release beta 1? Or does it > mean we would *like* to get these things in for beta 1? > > I actually don't mind either way - but if its the latter, then I need a > way of identifying the "must haves". These are the top priority items, > and at the moment I can't easily track their progress. > > Matt > > -- > SY, Dmitry Belyavsky > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: 3.0 beta 1 milestone
On Thu, 17 Sep 2020 18:49:19 +0200, Kurt Roeckx wrote: > > On Thu, Sep 17, 2020 at 01:48:18PM +0100, Matt Caswell wrote: > > So - this leads me to the question - what is the milestone for? Does it > > means these things *must* go in before we can release beta 1? Or does it > > mean we would *like* to get these things in for beta 1? > > We need to have a decision about those before beta 1, which can > include: > - It should be in beta 1 > - It doesn't block beta 1, before the 3.0 release is fine too, > which just means that you change the milestone to 3.0 > - It doesn't go into 3.0. No idea what the best way to tag them > is. Sorry, I realise I repeated what you said... Regarding things not going into 3.0.0, one way is not to assign a milestone to them. If we decide to do it that way, it probably means that we should set the 3.0.0 milestone on everything that we consider a bug fix rather than a new feature. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: New GitHub label for release blockers
On Sun, 13 Sep 2020 22:41:23 +0200, Dr. Matthias St. Pierre wrote: > > Conversely, there were also pull requests associated with the '3.0.0' or > '3.0.0 beta1' milestone, > without being associated to the '3.0 New Core + FIPS' project. This has > been fixed now. I fail to see why the milestones '3.0.0' / '3.0.0 beta1' must be 1:1 with the '3.0 New Core + FIPS' project. If we make them the same, what's the reason to have both? I just looked in the project, and these are issues and PRs the presence of which I think is questionable: #10612 #4930 #12860 #11311 Maybe there's a misunderstand of what "3.0 New Core" means. Please note the lack of comma. But if that doesn't help, how about the project description? I've seen a bit too much of wanting to pile *everything* into that project. That was never the intention. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Reordering new API's that have a libctx, propq
are that the intent wasn't originally as grand as you make it out to be. It was a name I came up with spur of the moment. Today, I wish I never had, at least in the public API (I'm less fussy about internal functions). It was a bad choice on my part. > IMO *the* most confusing thing would be to *change* an existing ordering > > (for example swap two existing parameters around). I see no problem with > adding new ones anywhere that's appropriate. > > Clearly we disagree on that - if you are making an extended version > of a function and you aren't keeping the same existing parameter > order (which you are not if you add or remove parameters which is > the point I was making - the order isn't the same as the existing > function because you've removed items - what you have is the order > of whatever parameters remain in the extended function are the same > - and that's a pretty pointless distinction to make - if you aren't > simply adding additional items on the end you make for a change over > mess and this I think we should be trying to avoid). I think we have some very fundamentaly different understanding of "order". I'm with Matt on this; if you have a list A, B, C, D and remove C, then A, B, D are still in the same order. As to where to add arguments, I would say that yes, it's good to have a general guideline, but that it will have to be decided more carefully on a per function basis. For example, I wouldn't necessarily add a property query string at the very end, if the algorithm name or the object the algorithm name can be derived from isn't there. So, I would not at all want to see something like this (this isn't what we have now, but with the idea that we always place OPENSSL_CTX as first argument and other added arguments last, this would be the result): OSSL_STORE_CTX * OSSL_STORE_open(OPENSSL_CTX *, const char *uri, const UI_METHOD *ui_method, void *ui_data, OSSL_STORE_post_process_info_fn post_process, void *post_process_data, const char *propq); Because the property query string is strongly associated with the implementation name (which is derived from the URI in this case), the more meaningful placement would be this: OSSL_STORE_CTX * OSSL_STORE_open(OPENSSL_CTX *, const char *uri, const char *propq, const UI_METHOD *ui_method, void *ui_data, OSSL_STORE_post_process_info_fn post_process, void *post_process_data, const char *propq); (that also follows the current _fetch function model) > My context there is for the users of the existing API. > It becomes especially problematic if you have type equivalence when > the order is changed around so there are no compiler warnings if the > user hasn't picked up on reordering of parameters. That is indeed a problem, but I fail to see how removed arguments or the location of added arguments matter much for this. Unless we get into +1 -1 situation and that a 'void *' just so happens to end up in a place that had a different type that gets silently passed anyway, I doubt that will be much of a problem. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Reordering new API's that have a libctx, propq
On Wed, 09 Sep 2020 16:08:10 +0200, Tomas Mraz wrote: > > On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote: > > > On 9 Sep 2020, at 9:38 pm, Tomas Mraz wrote: > > > > > > We could even provide a convenience thread local stack of lib > > > contexts > > > so the caller would not have to keep the old value but would just > > > push > > > the new libctx when entering and pop the old one when leaving. With > > > that, I think the changes needed in the application code would be > > > fairly simple and minimal. > > > > Let’s not overcomplicate things. > > We went through this discussion back when this was introduced. > > > > > > Push is: > > OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx); > > > > Pop is: > > OPENSSL_CTX_set0_default(prevctx) > > > > > > I don’t see having an explicit stack of these is of any benefit to > > anything but unwarranted complexity. > > There is one thing where it would be IMO helpful - let's say libcurl > has a callback into a calling application. With the current API in > libcurl API calls you would put the > calls OPENSSL_CTX_set0_default(libctx)/OPENSSL_CTX_set0_default(prevctx > ) at the beginning and end. But you would have to save the prevctx > somewhere in the libcurl context structure because on callbacks you > would have to temoprarily reset the context to the prevctx value. If we > implemented real stack it would not be needed. But yeah, I am not sure > this convenience is that much worth it. A stack becomes potentially extra churn in memory allocation for every push, and wondering what to do with the stack if the stack functionality fails. So yeah, I'm thinking that it's not really worth it. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Reordering new API's that have a libctx, propq
On Wed, 09 Sep 2020 13:38:42 +0200,
Tomas Mraz wrote:
> > Regarding model 3, it must be said that there is potential for
> > confusion
> > on what it's supposed to do, replace the default property query
> > string
> > (settable with EVP_set_default_properties()), or merge with it.
> > Remember that a property query string given through any XXX_fetch()
> > function is temporarly merged with the default properties when
> > looking
> > for fitting algorithms.
>
> Here I would actually argue, that there should be another property
> query in the libctx in addition to the default, that would have the
> exactly same semantics as the propq parameter has now and for the
> functions with the propq parameter it even would not be applied. How to
> name it so it won't be confused with the default property query, that's
> hard to say though.
"current" was mentioned several times during yesterday's videocall,
that could actually be used for a name.
I'm ok with putting such a property query string into the library
context, As Long As there is the understanding that it's not *tied*
to that library context, i.e. it can be used to pass a property query
string on to a provider implementation, to be used with whatever
library context the provider uses (the FIPS module has its own, for
example).
Side note: the function OPENSSL_CTX_set0_default() is a confusing
name, as there's an internal default ("default default", "ultimate
default"?) library context already, it's possible that we should
rename that to OPENSSL_CTX_set0_current().
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Re: Reordering new API's that have a libctx, propq
ng to be noted is that model 2 and 3 is possible to combine, which could give us a smoother transition between the current API and whatever we design going forward. Regarding the property query string, looking at it separate from the library context, the question remains where to put it, and a few proposals are on the table: 1. Put it last. 2. Put it next to the algorithm name or the object that an algorithm name is inferred from. 3. Set it "globally" with a thread local variable, a bit like what OPENSSL_CTX_set0_default() does for library contexts. For this model, it's been argued if it should simply be stored in the current library context, thereby avoiding to add another thread local variable (which, for all intents and purposes, is another actually global thing to deal with, even though on per-thread level). In my mind, model 2 would be more sensible than model 1, because of the implied tie between algorithm name and property query string. Also, even here, model 3 is possible to combine with model 2, and even with model 1. Regarding model 3, it must be said that there is potential for confusion on what it's supposed to do, replace the default property query string (settable with EVP_set_default_properties()), or merge with it. Remember that a property query string given through any XXX_fetch() function is temporarly merged with the default properties when looking for fitting algorithms. Thoughts? Cheers, Richard [*] The OpenSSL API could do with a re-design, but that's for the farther future and requires a lot of thought and time. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Reordering new API's that have a libctx, propq
On Sun, 06 Sep 2020 23:40:53 +0200, SHANE LONTIS wrote: > > If it is decided that the libctx is more important then the API > should really be something like this.. > OSSL_LIBCTX_MD_fetch(), (and I dont know if that is a good idea.).. I would rather not see that. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Reordering new API's that have a libctx, propq
There are many red herrings in here, and I would argue that trying to be too uniform in the way you think about all functions may be harmful, because not all functions are classified the same. We cannot deny that many of our interfaces have an OOP flair. We may be programming in C, but we very obviously have that kind of pattern, a "poor man's OOP" in C. So speaking about our interfaces in OOP terms is not far fetched, as long as we keep in mind that we can only take the argument so far. I would argue that EVP_XXX_get_whatever() / EVP_XXX_get_whatever() are classic accessors, and I assume that we have all been brought up with the description of "this" as the hidden first argument to any class method in C++, so it's not very far fetched to emulate that in C by making the instance you want details from or change details of as the (explicit) first argument. I would further argue that EVP_XXX_fetch() is a constructor (of an instance of EVP_XXX), and that with the assumption that there is no "this" in a constructor, the discussion about the arguments and their order must be different. What I hear, even though not in such terms, is an argument of the what the library context is and how that should affect the interface. In relation to EVP_XXX_fetch(), it seems to be more of a factory (or strictly speaking, the pool of resources, with hidden factory functions), and depending on the factory model you lean on, it might or might not be sensible to have it as first argument. My you, I'm trying quite hard to see it from a fresh user experience (as far as I can imagine it... after all, 20ish years with my fingers deep in OpenSSL entrails makes you not so fresh). I think, BTW, that this really comes down to how we view the library context. So far, I've seen all these interpretations (not all said explicitly, but clearly visible in code or how we argue about it): - framework - scope (I'm unsure if that differs much from framework) - factory / factory pool - bag of resources Personally, I have zero problems viewing it as all of these combined, but that requires us to be clear on how it's used in different places. Cheers, Richard On Sat, 05 Sep 2020 23:18:21 +0200, Tim Hudson wrote: > > > On Sun, Sep 6, 2020 at 6:55 AM Richard Levitte wrote: > > I'd rank the algorithm name as the most important, it really can't do > anything of value without it. > > It also cannot do anything without knowing which libctx to use. Look at the > implementation. > Without the libctx there is no "from-where" to specify. > > This is again hitting the concept of where do things come from and what is a > default. > Once "global" disappears as such, logically everything comes from a libctx. > > Your argument is basically "what" is more important than "from" or "where". > And the specific context here is where you see "from" or "where" can be > defaulted to a value so it > can be deduced so it isn't (as) important in the API. > > That would basically indicate you would (applying the same pattern/rule in a > different context) > change: > > int EVP_PKEY_get_int_param(EVP_PKEY *pkey, const char *key_name, int *out); > > To the following (putting what you want as the most important rather than > from): > > int EVP_PKEY_get_int_param(char *key_name, EVP_PKEY *pkey, int *out); > > Or pushing it right to the end after the output parameter: > > int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey); > > The context of where things come from is actually the most critical item in > any of the APIs we > have. > Even though what you want to get from where you want to get it is in the > point of the API call you > need to specify where from first as that context sets the frame of the call. > > Think of it around this way - we could have an implementation where we > remember the last key that > we have used and allow you to simply indicate you use the last key or if we > didn't want the last > key used to be able to specify it via a non-NULL pointer. This isn't that > unusual an API but not > something I'm suggesting we add - just trying to get the point across that > you are still thinking > of global and libctx as something super special with an exception in its > handling rather than > applying a general rule which is pretty much what we use everywhere else. > > And in which case where you generally don't provide a reference as there is > some default meaning > for it in general and can provide a reference for that sort of API would this > make sense to you: > > int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey); > > If pkey is NULL then you use the last key that you referenced, if it is not
Re: Reordering new API's that have a libctx, propq
the caller needs to always > specify a value for each > argument, which are always positional) in the sense that they can pass NULL > as a value rather than > a pointer to a fully instantiated object of the required type. > Even more so given that, excluding a minority of cases, we can expect > consumers of the APIs taking > libctx and propq as arguments to pass NULL for both of them and rely on the > openssl config > mechanism. > > So while I agree with Tim that sometime it is valuable to make a difference > among the consequences > of passing NULL as arguments in the context of one kind of function and > another, I believe the > place for that is the documentation not its signature. > The signature of the function should be designed for consumer usability, and > the conventional > pattern there seems to be > - required args > - optional args > - callback+cb_args > and inside each group the "importance" factor should be the secondary sorting > criteria. > > "importance" is probably going to be affected by the difference you are > making (or my > understanding of it): e.g. if a function took both libctx and bnctx, the fact > that a valid > pre-existing libctx is required to work (and a global already existing one > will be retrieved in > case none is given), while a fresh short-lived bnctx is going to be created > only for the lifetime > of the called function in case none is given seems to indicate that libctx is > of vital importance > for the API functionality, while bnctx is of minor relevance. > > But... going this way as a generalized approach, would bring us to the "add > in the middle" > scenario that we'd like to avoid. > I recognize that this is a point you already made in your original writeup, > as the tendency of > "add to the end" to naturally degrade into "add in the middle". > > So, my question is: if "degradable add to the end" (where "degradable" only > happens rarely and for > good reasons) seems the one that in the end produces signatures matching > (IMHO) the conventional > usability patterns expected by consumers of the API, is it such a dramatic > conclusion that we want > to exclude it? > > Or is your point that we are writing in C, all the arguments are positional, > none is ever really > optional, there is no difference between passing a `(void*) NULL` or a valid > `(TYPE*) ptr` as the > value of a `TYPE *` argument, so "importance" is the only remaining sorting > criteria, hence > (libctx, propq) are always the most important and should go to the beginning > of the args list > (with the exception of the `self/this` kind of argument that always goes > first)? > > Nicola > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE in progress: Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE
Votes have been cast, and the verdict is: accepted: yes (for: 5, against: 1, abstained: 4, not voted: 1) Cheers, Richard On Tue, 18 Aug 2020 13:15:46 +0200, Richard Levitte wrote: > > topic: Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE > >The rationale is that it makes things easier on programmers >(encode / decode is easier to write than serialize / deserialize), >and also avoids disputes on what is and isn't serialization. > >Associated issues and PRs: #12455, #12659 and #12660 > > Cheers, > Richard > > -- > Richard Levitte levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > ___ > otc mailing list > o...@openssl.org > https://mta.openssl.org/mailman/listinfo/otc > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
OTC VOTE in progress: Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE
topic: Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE The rationale is that it makes things easier on programmers (encode / decode is easier to write than serialize / deserialize), and also avoids disputes on what is and isn't serialization. Associated issues and PRs: #12455, #12659 and #12660 Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ otc mailing list o...@openssl.org https://mta.openssl.org/mailman/listinfo/otc
Re: API renaming
We're talking APIs (*), that includes the types. So yes, that's a safe assumption. Cheers, Richard (*) if people stopped using "API" when they mean "function", that would save the world from a pile of confusion. On Thu, 23 Jul 2020 18:45:49 +0200, Short, Todd wrote: > > > They also correspond directly to EVP_MAC and EVP_KDF types. Would the types > change as well? > -- > -Todd Short > // tsh...@akamai.com > // “One if by land, two if by sea, three if by the Internet." > > On Jul 23, 2020, at 11:56 AM, Matt Caswell wrote: > > On 23/07/2020 16:52, Richard Levitte wrote: > > On Thu, 23 Jul 2020 12:18:10 +0200, > Dr Paul Dale wrote: > > There has been a suggestion to rename EVP_RAND to OSSL_RAND. > This seems reasonable. > Would it > also make sense to rename the other new APIs similarly. > More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF > respectively? > > This is a good question... > > Historically speaking, even though EVP_MAC and EVP_KDF are indeed new > APIs, they have a previous history of EVP APIs, through EVP_PKEY. The > impact of relocating them outside of the EVP "family" may be small, > but still, history gives me pause. > > RAND doesn't carry the same sort of history, which makes it much > easier for me to think "just do it and get it over with"... > > I have the same pause - so I'm thinking just RAND for now. > > Matt > > > No public key for CFC553A2BA1A0ED1 created at 2020-07-23T18:45:49+0200 using > RSA -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: API renaming
I'm fine with that, really.
I have a preference for OSSL_, but if we look through the source,
there's reason for either. So far, we've majorly used OPENSSL_ for
things like feature macros (disabling macros, really), environment
variables, that sort of thing, while OSSL_ has become the primary
choice for new APIs ("less klunky", I think the judgement was in that
past discussion I keep referring to).
And yeah, I hear you from all the way around the planet, there are
some recent name choice that were made that give pause and are
arguably a mistake in this regard. EVP_MAC and EVP_KDF could have
been OSSL_MAC and OSSL_KDF. OPENSSL_CTX could have been OSSL_CTX.
I have no problem recognising that. But, they are there, even though
only in master (*). This is question of what we do going forward (a
yet unmerged PR with a new API is as good a target as any).
Cheers,
Richard
(*) I'm not sure I see master as something untouchable in this regard,
as the development is still not frozen (alpha), so I for one could
easily see a rename fest happening, should we decide for it. That
must happen before we enter the beta phase, though...
On Fri, 24 Jul 2020 07:55:10 +0200,
SHANE LONTIS wrote:
>
> For (1) the use of either ‘OPENSSL_' OR ‘OSSL_’ is not a particularly great
> rule either.
> We should decide which one to use and stick to it.
>
> > On 24 Jul 2020, at 3:20 pm, Richard Levitte wrote:
> >
> > A couple of points:
> >
> > 1. Quite a while ago, we (the team at the time) made a decision to
> >have all new APIs prefixed with 'OPENSSL_' or 'OSSL_'. It seems
> >that we never voted on it, though, but still.
> >
> > 2. The new RAND API hasn't been merged yet, so it's not like we're
> >renaming something that already exists.
> >
> > So in terms of "it's just a prefix", OSSL_ would be just as suitable.
> > It's a bit more blatantly "OpenSSL", though.
> >
> > Cheers,
> > Richard
> >
> > On Thu, 23 Jul 2020 23:30:25 +0200,
> > Tim Hudson wrote:
> >> Placing everything under EVP is reasonable in my view. It is just a prefix
> >> and it really has no
> >> meaning these days as it became nothing more than a common prefix to use.
> >>
> >> I don't see any significant benefit in renaming at this point - even for
> >> RAND.
> >>
> >> Tim.
> >>
> >> On Fri, 24 Jul 2020, 1:56 am Matt Caswell, wrote:
> >>
> >>On 23/07/2020 16:52, Richard Levitte wrote:
> >>> On Thu, 23 Jul 2020 12:18:10 +0200,
> >>> Dr Paul Dale wrote:
> >>>> There has been a suggestion to rename EVP_RAND to OSSL_RAND. This seems
> >>>> reasonable. Would
> >>it
> >>>> also make sense to rename the other new APIs similarly.
> >>>> More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF
> >>>> respectively?
> >>>
> >>> This is a good question...
> >>>
> >>> Historically speaking, even though EVP_MAC and EVP_KDF are indeed new
> >>> APIs, they have a previous history of EVP APIs, through EVP_PKEY. The
> >>> impact of relocating them outside of the EVP "family" may be small,
> >>> but still, history gives me pause.
> >>>
> >>> RAND doesn't carry the same sort of history, which makes it much
> >>> easier for me to think "just do it and get it over with"...
> >>
> >>I have the same pause - so I'm thinking just RAND for now.
> >>
> >>Matt
> >>
> >>
> > --
> > Richard Levitte levi...@openssl.org
> > OpenSSL Project
> > https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!KL97HvjYmS7a3QKC8tJzRlM2dM4t9WLQOYHSX50pDVuxB5XrRy5zA3onhN1dMVGCCw$
> >
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Re: API renaming
Er, I don't feel like I was part of this "we". I was very much part of the discussion that introduced OSSL_ and OPENSSL_ as a common prefix, thought... actually only three years ago. (historical note: I had written the STORE API, using STORE_ as a prefix, but that was judged too common, and that's what sparked the discussion at the time... and that's why we now have a OSSL_STORE) Cheers, Richard On Fri, 24 Jul 2020 07:26:23 +0200, Dr Paul Dale wrote: > The exact same points apply to EVP_MAC & EVP_KDF. > > We have also been telling people “use EVP” for ages. > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > On 24 Jul 2020, at 3:20 pm, Richard Levitte wrote: > > A couple of points: > > 1. Quite a while ago, we (the team at the time) made a decision to >have all new APIs prefixed with 'OPENSSL_' or 'OSSL_'. It seems >that we never voted on it, though, but still. > > 2. The new RAND API hasn't been merged yet, so it's not like we're >renaming something that already exists. > > So in terms of "it's just a prefix", OSSL_ would be just as suitable. > It's a bit more blatantly "OpenSSL", though. > > Cheers, > Richard > > On Thu, 23 Jul 2020 23:30:25 +0200, > Tim Hudson wrote: > > Placing everything under EVP is reasonable in my view. It is just a > prefix and it really > has no > meaning these days as it became nothing more than a common prefix to > use. > > I don't see any significant benefit in renaming at this point - even > for RAND. > > Tim. > > On Fri, 24 Jul 2020, 1:56 am Matt Caswell, wrote: > >On 23/07/2020 16:52, Richard Levitte wrote: > > On Thu, 23 Jul 2020 12:18:10 +0200, > Dr Paul Dale wrote: > > There has been a suggestion to rename EVP_RAND to OSSL_RAND. > This seems > reasonable. Would > >it > > also make sense to rename the other new APIs similarly. > More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and > OSSL_KDF respectively? > > This is a good question... > > Historically speaking, even though EVP_MAC and EVP_KDF are indeed > new > APIs, they have a previous history of EVP APIs, through EVP_PKEY. > The > impact of relocating them outside of the EVP "family" may be > small, > but still, history gives me pause. > > RAND doesn't carry the same sort of history, which makes it much > easier for me to think "just do it and get it over with"... > >I have the same pause - so I'm thinking just RAND for now. > >Matt > > -- > Richard Levitte levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: API renaming
A couple of points: 1. Quite a while ago, we (the team at the time) made a decision to have all new APIs prefixed with 'OPENSSL_' or 'OSSL_'. It seems that we never voted on it, though, but still. 2. The new RAND API hasn't been merged yet, so it's not like we're renaming something that already exists. So in terms of "it's just a prefix", OSSL_ would be just as suitable. It's a bit more blatantly "OpenSSL", though. Cheers, Richard On Thu, 23 Jul 2020 23:30:25 +0200, Tim Hudson wrote: > Placing everything under EVP is reasonable in my view. It is just a prefix > and it really has no > meaning these days as it became nothing more than a common prefix to use. > > I don't see any significant benefit in renaming at this point - even for RAND. > > Tim. > > On Fri, 24 Jul 2020, 1:56 am Matt Caswell, wrote: > > On 23/07/2020 16:52, Richard Levitte wrote: > > On Thu, 23 Jul 2020 12:18:10 +0200, > > Dr Paul Dale wrote: > >> There has been a suggestion to rename EVP_RAND to OSSL_RAND. This > seems reasonable. Would > it > >> also make sense to rename the other new APIs similarly. > >> More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF > respectively? > > > > This is a good question... > > > > Historically speaking, even though EVP_MAC and EVP_KDF are indeed new > > APIs, they have a previous history of EVP APIs, through EVP_PKEY. The > > impact of relocating them outside of the EVP "family" may be small, > > but still, history gives me pause. > > > > RAND doesn't carry the same sort of history, which makes it much > > easier for me to think "just do it and get it over with"... > > I have the same pause - so I'm thinking just RAND for now. > > Matt > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: API renaming
On Thu, 23 Jul 2020 12:18:10 +0200, Dr Paul Dale wrote: > There has been a suggestion to rename EVP_RAND to OSSL_RAND. This seems > reasonable. Would it > also make sense to rename the other new APIs similarly. > More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF respectively? This is a good question... Historically speaking, even though EVP_MAC and EVP_KDF are indeed new APIs, they have a previous history of EVP APIs, through EVP_PKEY. The impact of relocating them outside of the EVP "family" may be small, but still, history gives me pause. RAND doesn't carry the same sort of history, which makes it much easier for me to think "just do it and get it over with"... Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Naming conventions
On Fri, 03 Jul 2020 11:25:37 +0200,
Matt Caswell wrote:
> On 19/06/2020 08:15, Tomas Mraz wrote:
> > to something like:
> >
> > int EVP_MacInit(EVP_MAC_CTX *ctx);
> >
> > int EVP_MacUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t
> > datalen);
> >
> > int EVP_MacFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t
> > outsize);
> >
> > or at least
> >
> > int EVP_MACInit(EVP_MAC_CTX *ctx);
> >
> > int EVP_MACUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t
> > datalen);
> >
> > int EVP_MACFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t
> > outsize);
> >
> > Should we do that? I hope for the sheer ugliness of the supposedly
> > consistent names that we do not.
>
> This pattern is not universally used (as you mention the EVP_PKEY
> API does something different).
Er, you've choose what you wanted to read, I suppose... For fairly
high level EVP APIs, the CamelCase form is actually quite consistent.
For EVP_PKEY, we have them covering most if not all higher level
usages:
EVP_Sign{Init, Update, Final}
EVP_Verify{Init, Update, Final}
EVP_Open{Init, Update, Final}
EVP_Seal{Init, Update, Final}
> I remain strongly opposed to this renaming as I really don't think it
> helps to do this sort of thing now. It just introduces significant
> confusion without a long term strategy. We are too close to 3.0 beta1 to
> embark on this journey now. I'm also not convinced that strategically
> this is the right pattern to use.
What I hear from this is that 3.0 is the wrong time to introduce a new
(and hopefully better) public API, that we should post-pone that to
something like 4.0. I can get along with that line of thought.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Re: Naming conventions
This discussion seems to have gone stale. As far as I can read the thread, there are three lines of thought at play (in no special order): - the API put forth in #11996 and #11997 - the API exemplified with EVP_MAC and EVP_KDF before #11996 and #11997 - the API exemplified by functions in CamelCase I'm uncertain if we mean to say that only new EVP features (sometimes called sub-APIs) should be affected by whatever we decide, or if we should make appropriate aliases for older EVP features as well (one might argue that the CamelCase functions pave a way that avoids such aliases). Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Naming conventions
On Fri, 19 Jun 2020 09:15:22 +0200, Tomas Mraz wrote: > The problem is that there is not really fully consistent convention > followed currently (even in 1.1.1, not counting the API additions in > 3.0). > > For example if we would like to follow the convention _fully_ we would > have to rename these new EVP_MAC functions: > > int EVP_MAC_init(EVP_MAC_CTX *ctx); > > int EVP_MAC_update(EVP_MAC_CTX *ctx, const unsigned char *data, size_t > datalen); > > int EVP_MAC_final(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t > outsize); > > to something like: > > int EVP_MacInit(EVP_MAC_CTX *ctx); > > int EVP_MacUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t > datalen); > > int EVP_MacFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t > outsize); > > or at least > > int EVP_MACInit(EVP_MAC_CTX *ctx); > > int EVP_MACUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t > datalen); > > int EVP_MACFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t > outsize); Someone's walking memory lane ;-) I had to look back at OpenSSL_0_9_1c to remind myself, 'cause today, we're quite mixed up, what with the slightly lower level functions EVP_PKEY_sign_init, EVP_PKEY_sign, etc etc etc... I would say, thought, that if you want to do the higher level function thing (which are all CamelCase as far as I can see), there's another naming convention going on, at least with EVP_PKEY, it seems to be done according to the higher level operation you want to perform, not the type of data used to do it... what do you normally to with a MAC? So: int EVP_AuthenticateInit(EVP_MAC_CTX *ctx); int EVP_AUthenticateUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); int EVP_AUthenticateFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); ... or something like that. Quite frankly, a naming convention that is about the operation rather than the type of any type is something I could play along with. > And I actually hope we could add at least non-CamelCase aliases to the > existing (non-deprecated) CamelCase functions because they were always > the worst offender of the API consistency. I agree with you... but we have to recognise that would be a bigger remake, and if we do look at just the CamelCase API, it's actually fairly consistent (turning a blind eye at DigestSign quirkiness when I say that). (I suppose that CamelCase was inspired by the time, it was quite popular in certain circles in the 90's, and got especially popularised by Microsoft... and well, there are quite a few Microsoft ideas that have infiltrated OpenSSL... need I mention '_ex'?) Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Naming conventions
On Thu, 18 Jun 2020 16:36:30 +0200, Matt Caswell wrote: > On 18/06/2020 13:03, Richard Levitte wrote: > > As for not doing something piecemeal, I actually disagree, I see > > benefit in more than just one person getting their hands dirty (plus > > changing everything in one go may be overwhelming, and would make for > > another huge PR that takes overly much time to get through). However, > > as strategies go, and if we agree on making the change, we could very > > well create an issue for each affected sub-API and have it point at a > > common page that describes what we agreed upon... this could be a > > good use of the github wiki tab, for example. > > I don't mean piecemeal in the sense of doing it spread over a number of > PRs. I mean piecemeal in the sense of doing it spread over a number of > releases. As far as I can tell #11996 and #11997 were one offs without > any long term strategy in mind to convert the whole API in this way. Ah, ok. I agree with you there, if we're doing this, we should do it consistently for the same release. > > When do you see that time being, then? 3.1 (we've talked about it > > being a "cleanup" release)? 4.0? > > Perhaps never. But if we do it then either 3.1 or 4.0 could be > considered. I am yet to be convinced that its worth it. I actually have a different idea, but that's much more further in the future: a consistent libcrypto API across the board, where all libcrypto functions are in the "namespaces" (i.e. are prefixed with) OSSL or OPENSSL. No exception. That idea would be a fairly complete API remake, and I do think it would be worth the while. So uhm, "never" isn't a line of thinking that I'm ready to accept. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Naming conventions
On Thu, 18 Jun 2020 12:36:52 +0200, Matt Caswell wrote: > > EVP_MAC_CTX_new -> EVP_MAC_new_ctx > EVP_MAC_CTX_free -> EVP_MAC_free_ctx > EVP_MAC_CTX_dup -> EVP_MAC_dup_ctx > EVP_MAC_CTX_mac -> EVP_MAC_get_ctx_mac > EVP_MAC_CTX_get_params -> EVP_MAC_get_ctx_params > EVP_MAC_CTX_set_params -> EVP_MAC_set_ctx_params > > There are similar renamings for the KDF APIs. > > I am opposed to this renaming on the basis that it is inconsistent with > what we do elsewhere. Okie, if we're going to start this discussion with taking a stand, I guess I'll declare that while I initially had the exact same concern, I now see this change in a positive light. This comment from #11997 got me to change my mind: The already established patterns is a furphy. I'll reword it more precisely: we've done things badly in the past, thus we should do them badly moving forwards. We've always been at war with Eurasia.oh wrong context, it's Eastasia. Ref: https://github.com/openssl/openssl/pull/11997#issuecomment-636658901 For historical background, changing the function name pattern isn't a new discussion, it's even been brought up on this list more than a year ago: https://mta.openssl.org/pipermail/openssl-project/2019-March/001280.html Unfortunately, those discussion never got much traction. I'm not at all surprised that #11996 and #11997 came to be, it follows a fairly human pattern that when talking leads nowhere and someone is still engaged enough, action will happen. When it comes to EVP_MAC and EVP_KDF, those sub-APIs already break with existing patterns, albeit more subtly. They have a _dup function, where previous sub-APIs have a _copy function. But that's perhaps small enough to be acceptable. > For example, except for the MAC/KDF APIs I see > there are 26 functions of the form: > > FOO_CTX_new > > The case is similar for FOO_CTX_free. Aside from the newly introduced > MAC/KDF names there are no other instances of FOO_new_ctx or > FOO_free_ctx. This is totally inconsistent and, IMO, will cause > significant confusion for our users. Sure, but it counters the confusion with when to use FOO and when to use FOO_CTX as a prefix. You and I seem to be pretty clear on this, but I've seen enough questions on the matter to see the benefit with this change, even though it breaks the old pattern. > "If we want to change the naming conventions then we should do so only > after agreeing what those conventions should be, and agreeing a strategy > for how we are going to apply them. It should not be done piecemeal (and > hidden away in a PR that supposedly made things more consistent but in > reality did the opposite)." I agree that it would have been good to discuss it further first. However, those discussion have been met with utter silence before, so that wasn't very fruitful. I guess that #11996 and #11997 was enough of a slap to wake us up. As for not doing something piecemeal, I actually disagree, I see benefit in more than just one person getting their hands dirty (plus changing everything in one go may be overwhelming, and would make for another huge PR that takes overly much time to get through). However, as strategies go, and if we agree on making the change, we could very well create an issue for each affected sub-API and have it point at a common page that describes what we agreed upon... this could be a good use of the github wiki tab, for example. > There *are* inconsistencies and quirks in our current naming > conventions. I am skeptical that now is the time to resolve them given > the number of other changes we are already introducing into 3.0. When do you see that time being, then? 3.1 (we've talked about it being a "cleanup" release)? 4.0? Each choice has its pros and cons: - Pros for 3.1: we get the added API variants out fairly early. - Cons for 3.1: because of ABI compatibility concerns, the old functions will have to be preserved as is and the new will have to be implemented as macros or new functions, making for a bigger libcrypto.num. - Pros for 4.0: ABI concerns aren't a factor, so the old functions can be renamed, and we can preserve the old names as macros. No need for double entries in libcrypto.num. - Cons for 4.0: By that's far away, which means that we solidify the old pattern even more before remaking it. Side note: if we get through a rename fest, can we get rid of CamelCase? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Monthly Status Report (May 2020)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development - [not_yet_merged] [WIP] Refactor CPUID code (PR openssl/openssl#11311) - EVP: Only use the engine when one is defined, in pkey_mac_ctrl() (PR openssl/openssl#11674) - WPACKET: don't write DER length when we don't want to (PR openssl/openssl#11703) - util/perl/OpenSSL/OID.pm: remove the included unit test (PR openssl/openssl#11704) - Fix reason code clash (PR openssl/openssl#11708) - PSS pack: Add provider support for PSS parameters (PR openssl/openssl#11710) - Configure: avoid perl regexp bugs (PR openssl/openssl#11737) - EVP: when setting the operation to EVP_PKEY_OP_UNDEFINED, clean up! (PR openssl/openssl#11750) - Warn that objects with opaque types must never be passed on. (PR openssl/openssl#11754) - OSSL_STORE additions (PR openssl/openssl#11756) - Fix some misunderstandings in our providers' main modules (PR openssl/openssl#11777) - Fix d2i_PrivateKey_ex() to work as documented (PR openssl/openssl#11787) - Fix CHANGES.md issues reported by markdownlint (PR openssl/openssl#11788) - Remove explicit dependency on configdata.pm when processing .in files (PR openssl/openssl#11790) - PROV: Add a proper provider context structure for OpenSSL providers (PR openssl/openssl#11803) - SSL: refactor ssl_cert_lookup_by_pkey() to work with provider side keys (PR openssl/openssl#11828) - test/evp_extra_test.c: Add OPENSSL_NO_CMAC around CMAC test (PR openssl/openssl#11833) - CORE: Fix a couple of bugs in algorithm_do_this() (PR openssl/openssl#11837) - CORE: query for operations only once per provider (unless no_store is true) (PR openssl/openssl#11842) - Add OSSL_PROVIDER_do_all() (PR openssl/openssl#11858) - Refactor the provider side DER constants and writers (PR openssl/openssl#11868) - rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx(): fix check of |md| (PR openssl/openssl#11869) - STORE: Make try_decode_PrivateKey() ENGINE aware (PR openssl/openssl#11872) - Fix d2i_PrivateKey() to work as documented [1.1.1] (PR openssl/openssl#11888) - PROV: Fix RSA-OAEP memory leak (PR openssl/openssl#11927) - Add header file docs for openssl/core_numbers.h and openssl/core_names.h (PR openssl/openssl#11963) - util/mkpod2html.pl: Fix unbalanced quotes (PR openssl/openssl#11969) - Fix EVP_CIPHER_fetch race condition (PR openssl/openssl#11977) - [not_yet_merged] [WIP] EVP: retrieve EVP_CIPHER constants in the evp_cipher_from_dispatch() (PR openssl/openssl#11980) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Late Monthly Status Report (March 2020)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development - [not_yet_merged] WIP: apps: Switch to using OSSL_STORE for loading keys, certs, ... (PR openssl/openssl#7390) - Implement domparam and key generation (PR openssl/openssl#10289) - DOC: Add documentation related to X509_LOOKUPs [1.1.1] (PR openssl/openssl#11120) - Refactor CRMF_poposigningkey_init() to work with provider keys (PR openssl/openssl#11126) - Configuration: Add post module building check (PR openssl/openssl#11170) - build.info extensions: variable value substitutions and multi-item statements (PR openssl/openssl#11185) - .travis.yml: where it matters, have build and source nesting levels differ (PR openssl/openssl#11186) - crypto/perlasm/x86_64-xlate.pl: detect GNU as to deal with quirks (PR openssl/openssl#11191) - EVP: Check that key methods aren't foreign when exporting (PR openssl/openssl#11193) - Andoid cross compile: change ANDROID_NDK_HOME to ANDROID_NDK_ROOT (PR openssl/openssl#11206) - config, Configure: move the check of removed crypto/ sub-systems (PR openssl/openssl#11217) - Configurations: Fix "android" configuration target (PR openssl/openssl#11238) - util/wrap.pl: do not look at EXE_SHELL (PR openssl/openssl#11258) - Restructure documentation of implementations in providers (PR openssl/openssl#11270) - DOCS: Fix documentation on asymmetric keydata types (PR openssl/openssl#11275) - DOCS: Fix the description of OSSL_PARAM_allocate_from_text() (PR openssl/openssl#11279) - Refactor sm2_id (PR openssl/openssl#11302) - Fix RSA structure (PR openssl/openssl#11315) - Fix legacy_ctrl_to_param() to pay better attention to keytype (PR openssl/openssl#11329) - Refactor sm2_id - addendum (PR openssl/openssl#11335) - EVP: fetch the EVP_KEYMGMT earlier (PR openssl/openssl#11343) - [WIP] EVP: Fix EVP_PKEY_copy_parameters() for a newly allocated |to| (PR openssl/openssl#11368) - DH, DSA, EC_KEY: Fix exporters to allow domain parameter keys (PR openssl/openssl#11374) - EVP: Downgrade keys rather than upgrade (PR openssl/openssl#11375) - util/wrap.pl: Correct exit code when signalled (PR openssl/openssl#11379) - EC: Refactor ec_curve_name2nid() to accept NIST curve names (PR openssl/openssl#11391) - PROV: Fix EC_KEY exporters to allow domain parameter keys (PR openssl/openssl#11394) * Web - Fix 'make relupd' -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Late Monthly Status Report (February 2020)
Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development - PROV: add RSA signature implementation (PR openssl/openssl#10557) - Disable devcryptoeng on newer OpenBSD versions [1.1.1] (PR openssl/openssl#10565) - EVP: Adapt EVP_PKEY checking, comparing and copying for provider keys (PR openssl/openssl#10807) - DOC: document in more detail what a BIO_read_ex() via BIO_f_buffer() does (PR openssl/openssl#10890) - Refactor SM2 (PR openssl/openssl#10942) - Decentralize legacy_ctrl_str_to_param() (PR openssl/openssl#10947) - config: ensure the perl Configure run is the last statement (PR openssl/openssl#10953) - EVP: Small refactor of keymgmt library code (PR openssl/openssl#10963) - DOC: Add documentation related to X509_LOOKUPs (PR openssl/openssl#10986) - Redesign the KEYMGMT libcrypto <-> provider interface (PR openssl/openssl#11006) - EVP: Adapt EVP_PKEY checking, comparing and copying for provider keys, take 2 (PR openssl/openssl#11025) - Configure: Add easy to use disabled deprecated functionality indicators (PR openssl/openssl#11027) - PROV: Ensure the AlgorithmIdentifier registers in DSA signature impl (PR openssl/openssl#11037) - X509_PUBKEY_set(): Fix memory leak (PR openssl/openssl#11038) - test/recipes/80-test_ssl_old.t: use 'openssl genpkey' (PR openssl/openssl#11041) - Make util/find-doc-nits runnable from the build tree (PR openssl/openssl#11045) - Refactor OSSL_PARAM_allocate_from_text() for better flexibility (PR openssl/openssl#11046) - Add OSSL_SERIALIZER_PUBKEY_TO_DER_PQ and friends (PR openssl/openssl#11055) - Adapt i2d_PrivateKey for provider only keys (PR openssl/openssl#11056) - Document OSSL_SERIALIZER_PUBKEY_TO_DER_PQ and friends (PR openssl/openssl#11071) - Refactor evp_pkey_make_provided() to do legacy to provider export (PR openssl/openssl#11074) - Adapt i2d_PUBKEY for provider only keys (PR openssl/openssl#11078) - TEST: Create test specific output directories (PR openssl/openssl#11080) - include/openssl/whrlpool.h: correct unbalanced deprecation guards (PR openssl/openssl#11087) - Fix VMS build [1.1.1 only] (PR openssl/openssl#11088) - PROV: Build the main FIPS module code with FIPS_MODE defined (PR openssl/openssl#11090) - TEST: add util/wrap.pl and use it #0 (PR openssl/openssl#0) - Rethink the EVP_PKEY cache of provider side keys (PR openssl/openssl#11148) - VMS: mitigate for the C++ compiler that doesn't understand certain pragmas (PR openssl/openssl#11159) - Deprecate ASN1_sign(), ASN1_verify() and ASN1_digest() (PR openssl/openssl#11161) - Fix util/mktar.sh to use the new VERSION information (PR openssl/openssl#11190) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Late Monthly Status Report (January 2020)
Apart from normal business, such as normal reviews, OMC business,
normal system administration tasks, small fixes, etc., key activities
this month:
* Development
- [not_yet_merged] WIP: OSSL_STORE for providers
(PR openssl/openssl#9389)
- CORE & EVP: Adapt KEYEXCH, SIGNATURE and ASYM_CIPHER to handle key types
better
(PR openssl/openssl#10647)
- Configuration: synchronise the variables on the build file templates
(PR openssl/openssl#10753)
- EVP: Fix method to determine if a PKEY is legacy or not
(PR openssl/openssl#10758)
- DOCS: The interpretation of OPENSSL_API_COMPAT has changed, update docs
(PR openssl/openssl#10765)
- Add missing inclusion of "internal/deprecated.h"
(PR openssl/openssl#10766)
- EVP: If a key can't be exported to provider, fallback to legacy
(PR openssl/openssl#10771)
- Add the DSA serializers to the default provider tools
(PR openssl/openssl#10772)
- EVP: make EVP_PKEY_{bits,security_bits,size} work with provider only keys
(PR openssl/openssl#10778)
- PROV: Fix mixup between general and specialized GCM implementations
(PR openssl/openssl#10783)
- Configure: use $list_separator_re only for defines and includes
(PR openssl/openssl#10793)
- Eliminate some EVP_PKEY_size() uses
(PR openssl/openssl#10798)
- EVP: clear error when falling back from failed EVP_KEYMGMT_fetch()
(PR openssl/openssl#10803)
- CORE: renumber OSSL_FUNC_KEYMGMT macros
(PR openssl/openssl#10804)
- Fix documentation for EVP_DigestSign* and EVP_DigestVerify*
(PR openssl/openssl#10805)
- Fix EVP_Digest{Sign,Verify}Final() and EVP_Digest{Sign,Verify}() for
provider only keys
(PR openssl/openssl#10806)
- EVP: Adapt EVP_PKEY Seal and Open for provider keys
(PR openssl/openssl#10808)
- Move the definition of OPENSSL_BUILDING_OPENSSL
(PR openssl/openssl#10813)
- Change returned -2 to 0 in EVP_Digest{Sign,Verify}Init()
(PR openssl/openssl#10815)
- Add EVP_PKEY_get_default_digest_name()
(PR openssl/openssl#10824)
- CRYPTO: Remove support for ex_data fields when building the FIPS module
(PR openssl/openssl#10837)
- Modify EVP_CIPHER_is_a() and EVP_MD_is_a() to handle legacy methods too
(PR openssl/openssl#10845)
- Move the stored namemap pre-population to namemap construction
(PR openssl/openssl#10846)
- [1.1.1] Fix documentation of return value for EVP_Digest{Sign,Verify}Init()
(PR openssl/openssl#10847)
- Build file templates: Use explicit files instead of $< or $? for pods
(PR openssl/openssl#10849)
- EVP: Add evp_pkey_make_provided() and refactor around it
(PR openssl/openssl#10850)
- Adapt X509_PUBKEY_set() for use with provided implementations
(PR openssl/openssl#10851)
- For all assembler scripts where it matters, recognise clang > 9.x
(PR openssl/openssl#10855)
- Add GNU properties note for Intel CET in x86_64-xlate.pl
(PR openssl/openssl#10875)
- Configure: Better detection of '-static' in @{$config{LDFLAGS}}
(PR openssl/openssl#10878)
- PROV: Fix bignum printout in text serializers
(PR openssl/openssl#10891)
- OpenSSL::Test: bring back the relative paths
(PR openssl/openssl#10913)
- Adapt ASN1_item_sign_ctx() for use with provided keypairs
(PR openssl/openssl#10920)
- Add internal maxsize macros
(PR openssl/openssl#10928)
- test/recipes/30-test_evp.t: Fix multiple definition of @bffiles
(PR openssl/openssl#10944)
* Administration
- Stop making snaps for 1.1.0 and 1.0.2, and make 3.0-dev snaps
- Switch final review to be for OTC rather than OMC
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Re: The hold on PR 12089
On Wed, 10 Jun 2020 10:55:36 +0200, Nicola Tuveri wrote: > The matter of OMC Vs OTC vote also depends on what kind of hold Tim > is applying with his - 1: is it a OMC or a OTC hold? The label that Tim added should make it clear: "hold: need omc decision" I've started a discussion within the OMC. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: addrev warning
Yes. I propose telling git to shut up, i.e. FILTER_BRANCH_SQUELCH_WARNING=1 Our use of git-filter-branch isn't one that will generate a gotcha, or we would have seen that a long time ago... in other words, we treat it gently. I was looking at git-filter-repo, but realised that it's not a standard git thing, so if we changed addrev to use that instead, we'd have addrev starting to fail completely for everyone that hasn't installed that one yet. I'm not prepared to spring that surprise on anyone. Cheers, Richard On Mon, 08 Jun 2020 12:16:40 +0200, Matt Caswell wrote: > > After upgrading Ubuntu over the weekend I'm suddenly seeing this warning > from addrev. Is anyone else getting this? > > WARNING: git-filter-branch has a glut of gotchas generating mangled history >rewrites. Hit Ctrl-C before proceeding to abort, then use an >alternative filtering tool such as 'git filter-repo' >(https://github.com/newren/git-filter-repo/) instead. See the >filter-branch manual page for more details; to squelch this warning, >set FILTER_BRANCH_SQUELCH_WARNING=1. > Proceeding with filter-branch... > > > MMatt > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Travis jobs not getting started
This is something that has been ongoing for a while... it was in the back of my mind a while ago, but then I got distracted. Thanks for finding that document... I failed to when I looked a couple of weeks ago. Migration is now done. It won't show on existing PRs, but does show on new ones. The new Travis is a Github App, which means that it's much more integrated into Github; among others, that shows when you press "details", and it's also available via the new per-PR "Checks" tab. Cheers, Richard On Fri, 05 Jun 2020 13:27:20 +0200, Tomas Mraz wrote: > > Apparently the travis jobs are not getting started anymore for some > reason. > > It happened to me on the GitHub linux-pam project and the solution (or > workaround) was to migrate the project to the travis-ci.com. > > I just did it by following the instructions in this document: > https://docs.travis-ci.com/user/migrate/open-source-repository-migration/ > > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OMC VOTE: Drop the 'openssl' interactive mode as per GH #12023
4 voted for, none against, no abstencions, 3 have not yet voted. This PR will be merged. Cheers, Richard On Wed, 03 Jun 2020 12:46:41 +0200, Richard Levitte wrote: > > topic: Drop the 'openssl' interactive mode as per GH #12023 > comment: It is undocumented, pretty much unused, and hard to keep > stable. > Proposed by Richard Levitte > Public: yes > > -- > Richard Levitte levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
OMC VOTE: Drop the 'openssl' interactive mode as per GH #12023
topic: Drop the 'openssl' interactive mode as per GH #12023 comment: It is undocumented, pretty much unused, and hard to keep stable. Proposed by Richard Levitte Public: yes -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: error conversion macro's
We can, given time. This is one of those things that can be saved for the beta period, since it doesn't affect anything public. But sure, if someone feel inclined to do that earlier, I don't see why that should be a problem. Cheers, Richard On Fri, 15 May 2020 16:00:49 +0200, Salz, Rich wrote: > Perhaps the next Alpha release can do the error macro conversion? > > Add script to convert XXXerr() to XXXerror, > https://github.com/openssl/openssl/pull/9441 > > In particular, > https://github.com/openssl/openssl/pull/9441#issuecomment-522171044 > > It might need updating if any new “error facility” values have been added, > but I didn’t notice any > of them. > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Alpha2
On Wed, 13 May 2020 18:00:35 +0200, Matt Caswell wrote: > > On 08/05/2020 09:55, Matt Caswell wrote: > > Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss > > current progress. It was proposed that we should do the Alpha 2 release > > next week (on Thursday 14th May). Unless I hear objections otherwise, I > > plan to go with that. > > I'm currently thinking that we're not quite ready for alpha2 and I would > like to push it by a day. Any objections? Not from me... among others, I want to see #11758 in there... Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Alpha2
You might want to consider reviewing #11630, an reminding me what else needs to get fixed in there. On Fri, 08 May 2020 10:55:19 +0200, Matt Caswell wrote: > > Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss > current progress. It was proposed that we should do the Alpha 2 release > next week (on Thursday 14th May). Unless I hear objections otherwise, I > plan to go with that. > > Matt > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Technically an API break
On Thu, 07 May 2020 10:31:42 +0200, Tomas Mraz wrote: > > On Thu, 2020-05-07 at 09:24 +0100, Matt Caswell wrote: > > PR11589 makes a change to the public API function > > `SSL_set_record_padding_callback` to change its return type from void > > to > > int: > > > > https://github.com/openssl/openssl/pull/11589 > > > > This is technically an API break - but it doesn't seem too serious. > > It's > > possible, I suppose, that existing applications that use this will > > fail > > to spot the error return since this function can now fail. The > > function > > itself was only recently added (in 1.1.1), and I suspect real-world > > usage is very small (or possibly nil). > > > > Is this considered ok? > > I would say this is an acceptable thing if it is documented (which it > is in the PR). Especially because the error return can happen only when > the application sets up the SSL to use kernel TLS. I agree with this assessment. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Cherry-pick proposal
; On Wed, 29 Apr 2020 at 14:08, Matt Caswell wrote: > > The OTC have received this proposal and a request that we vote on it: > > I would like to request that we do not allow cherry-picks between master > and 1.1.1-stable because these two versions are now very different, if a > cherry-pick succeeds, there is no guarantee that the result will work. > Because we have no CI for the cherry-pick. If a cherry-pick is needed, a > new PR for 1.1.1 should be done and approved independently. > > Before starting a vote I'd like to provide opportunity for comments, and > also what the vote text should be. > > Thanks > > Matt > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Revisiting tradition: branches and tags
On Tue, 14 Apr 2020 09:28:26 +0200, Dr. Matthias St. Pierre wrote: > > > > Is it possible to set up alias names for the historical branches? > > > > It's possible yes. The hard part is 1.1.1. There *is* something > > called 'git symbolic-ref', but they can only be added in repos we have > > physical access to, so while can add those on our git server, and they > > will work, we cannot add them in github. > > > > Ref git help symbolic-ref > > Symbolic references are *not* the right solution to the problem IMO. They are > not equivalent to branches. > Checking out a symbolic reference leaves you in the 'detached HEAD' state: > > msp@msppc:~/src/openssl$ git symbolic-ref ossl111 > refs/heads/OpenSSL_1_1_1-stable > msp@msppc:~/src/openssl$ cd ../openssl-1.1.1 > msp@msppc:~/src/openssl-1.1.1$ git checkout ossl111 > Note: switching to 'ossl111'. > > You are in 'detached HEAD' state. You can look around, make experimental > changes and commit them, and you can discard any commits you make in this > state without impacting any branches by switching back to a branch. Okie. I hadn't experimented with that, so didn't know. That manual is fantastically unclear on what this command does too, at least the way I read it. I guess that's another nail in its coffin. > The proper way to do it IMO is to create new branch and tag > references for all the stable branches resp. release tags. ... > Currently, the only old-style branch which needs to be synchronized > is `OpenSSL_1_1_1-stable`. This could easily be done by the git > post-receive hook on git.openssl.org. In fact, all old-style branch > and tag references for all eol-branches could be removed > immediately. Good point. The posst-update hook should be usable for this. > We change the GitHub setup such that pull requests to stable > branches need to be based onto the new-style branches, but keep the > old-style stable branches in sync with the new-style branches for a > little while. Er... how do you change that Github setup? I thought it simply showed a list of all available branches regardless. So if we got a duplicate set, it's going to show both, isn't it? Considering that the github repo is a --mirror of the git.openssl.org repo, I'm not sure how the old branch refs would be filtered out... It seems to me like this discussion is splitting into two: 1) Start with new names for 3.0 and on (I can only see positive responses so far, even with Matt's hesitance) 2) Rename of the old names. As far as I can see, those two don't have to be in absolute sync, even though that would be desirable. In other words, we can figure out the details of 2 even after we've started 1. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
