From nobody Wed Mar 17 11:10:18 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0663A0FEF; Wed, 17 Mar 2021 11:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIG0AoAzIt0j; Wed, 17 Mar 2021 11:10:02 -0700 (PDT) Received: from dunkelfelder.tools.ietf.org (dunkelfelder.tools.ietf.org [217.69.81.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251A43A0FE5; Wed, 17 Mar 2021 11:10:02 -0700 (PDT) Received: from rjsparks by dunkelfelder.tools.ietf.org with local (Exim 4.84_2) (envelope-from ) id 1lMacJ-0006gq-UY; Wed, 17 Mar 2021 19:09:59 +0100 To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org Message-Id: From: Robert Sparks Date: Wed, 17 Mar 2021 19:09:59 +0100 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: rjsparks@nostrum.com X-SA-Exim-Scanned: No (on dunkelfelder.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] New xml2rfc release: v3.6.0 X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 18:10:07 -0000 Hi, This is an automatic notification about a new xml2rfc release, v3.6.0, generated when running the mkrelease script. Release notes: xml2rfc (3.6.0) ietf; urgency=medium ** Add pagination, bugfixes, drops Python 3.5 ** * Merged in [3899] from jennifer@painless-security.com: Prevent crash when column count varies between table rows. Fixes #512. * Merged in [3898] from jennifer@painless-security.com: Cite the abstract as 'Abstract' instead of 'Appendix Abstract'. Fixes #429. * Merged in [3893] from jennifer@painless-security.com: Modify selector to include rfc element in yes/no to true/false conversion. Fixes #457. * Merged in [3892] from jennifer@painless-security.com: Move conjunctions out of author elements in reference citations. Fixes #575. * Merged in [3891] from jennifer@painless-security.com: Remove quotes from in text writer. Fixes #563. * Merged in [3890] from jennifer@painless-security.com: Label xref to a cref with the anchor instead of 'Section X.Y'. Fixes #431. * Merged in [3887] and [3889] from jennifer@painless-security.com: Simplify text rendering of super/subscripts. Based on patch submitted by and refinement from subsequent list discussion. Fixes #590. * moved away test targets for untested versions of python * Merged in [3886] from mark@painless-security.com: Remove pilcrows from tables of contents In addition to searching list item descendants for the existence of previously-added pilcrows, the code now also searches the list item ancestors for any node that has the 'toc' class to indicate that it is part of a table of contents. If either are found, the pilcrow is not added. Fixes #568. * Merged in [3877] and [3878] from henrik@levkowetz.com: Made a --paginate/--pagination switch available, to force pagination for text output. * Merged in [3876] from henrik@levkowetz.com: Adjusted li > p margin to fit better with other list spacing, and to not let the

margin spill out from inside a

. FIxes issue #580. * Drop python 35 from tests * Updated manpage.txt and docfiles -- Robert Sparks 17 Mar 2021 18:53:29 +0100 The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. If there are system- installed python modules which pip will not upgrade, you may have to use 'pip install --upgrade --no-deps xml2rfc' and install dependencies manually. The new version is also available through SVN checkout, with 'svn checkout https://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/3.6.0' Documentation for this release is built-in, and also available at: https://xml2rfc.tools.ietf.org/xml2rfc-doc-3.6.0.html Regards, Robert Sparks (via the mkrelease script) From nobody Wed Mar 17 12:27:08 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF403A1220 for ; Wed, 17 Mar 2021 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FU3IP9kh7_N for ; Wed, 17 Mar 2021 12:27:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344CF3A1221 for ; Wed, 17 Mar 2021 12:27:04 -0700 (PDT) Received: from unformal.local ([47.186.1.92]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 12HJQxjs083833 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 17 Mar 2021 14:27:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1616009220; bh=2NE4pxoJ2UWcCzAQzn2aZC180JHomj//L6mfjj7Kst4=; h=Subject:To:References:From:Date:In-Reply-To; b=Xna36+PTB89h7Pk/niH6h+DbdIC0SYyU9EvVD2stBcmAitzpzBtqGJjGX+NsgQMQ1 MzXkHCUnzFa5rf88rosX8L9H5z0lby50J2MINx7cdNvdafyTuqZPOmyeoaH44YsoEd 5TQsjPzZ5L1icuYMqEdZ+vPgUI2p9Q8IzGDG5gmA= X-Authentication-Warning: raven.nostrum.com: Host [47.186.1.92] claimed to be unformal.local To: Daniel Kahn Gillmor , xml2rfc-dev@ietf.org References: <87y2flrr5y.fsf@fifthhorseman.net> From: Robert Sparks Message-ID: Date: Wed, 17 Mar 2021 14:26:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <87y2flrr5y.fsf@fifthhorseman.net> Content-Type: multipart/alternative; boundary="------------2565B941D4AE69F33F6DE4AE" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] cryptographic signatures over xml2rfc releases should not be made with SHA1 X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 19:27:07 -0000 This is a multi-part message in MIME format. --------------2565B941D4AE69F33F6DE4AE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel - You'll have seen that 3.6.0 was just released, and this comment has not yet been addressed. It's on the list to deal with. I wanted to make sure you knew this wasn't being ignored. RjS On 2/18/21 3:40 PM, Daniel Kahn Gillmor wrote: > Hi folks-- > > I'm looking at the latest xml2rfc tarball and its OpenPGP signature: > > https://files.pythonhosted.org/packages/c0/81/21281e78fd2afb8f5dfcb92b78c9dcd621081277304e0f25df0ee7c89c64/xml2rfc-3.5.0.tar.gz > https://files.pythonhosted.org/packages/c0/81/21281e78fd2afb8f5dfcb92b78c9dcd621081277304e0f25df0ee7c89c64/xml2rfc-3.5.0.tar.gz.asc > > The signature file (the *.asc) is made using SHA-1 for the signature: > > $ pgpdump < xml2rfc-3.5.0.tar.gz.asc > Old: Signature Packet(tag 2)(540 bytes) > Ver 4 - new > Sig type - Signature of a binary document(0x00). > Pub alg - RSA Encrypt or Sign(pub 1) > Hash alg - SHA1(hash 2) > Hashed Sub: signature creation time(sub 2)(4 bytes) > Time - Wed Nov 18 05:20:56 EST 2020 > Sub: issuer key ID(sub 16)(8 bytes) > Key ID - 0x4E9B574B8FBB171A > Hash left 2 bytes - d2 9f > RSA m^d mod n(4094 bits) - ... > -> PKCS-1 > $ > > Signatures using SHA-1 have been deprecated for over a decade now. No > modern tool should generate them. > > From the Version: comment in the .asc file, it looks to me like these > signatures are being generated from the old, deprecated "classic" > version of GnuPG ("Version: GnuPG v1"). > > Henrik (or whoever else might make a future release of xml2rfc), is > there something blocking you from updating to a more modern OpenPGP > implementation for making these signatures? The GnuPG 2.2.x series > ("modern") should make signatures with sha256 (or better) by default, as > should pretty much any other OpenPGP implementation (sequoia, > openpgp.js, gopenpgp, rnp, pgpainless, etc). There's probably also a > way to coax better-than-SHA-1 signatures out of GnuPG 1.x as well, but > that toolkit is unable to deal with modern tooling like ECC keys so i > recommend upgrading anyway. > > The irony here is that i'm trying to work on the RFC for OpenPGP itself > to refresh the cryptographic requirements in that standard, and i'm > working with modern tooling that deprecates SHA-1 signatures > appropriately; and to update the xml2rfc package i want to check the > OpenPGP signature, etc. a nice little loop! > > I figure it's probably neither possible nor advisable to re-issue a > signature over xml2rfc version 3.5.0, but if you can line it up so that > signatures of future releases avoid using SHA1, that'd be great. > > --dkg > > PS The files i've fetched from the above URLs have this content (just in > case anyone wants to replicate, they can confirm that they're getting > the same thing): > > $ sha256sum * > 3ec836a9545f549707a8c8176038160185b9d08c1dd80304a906527da21bff68 xml2rfc-3.5.0.tar.gz > ef652fda6c1f7b63f22765e7df48d627ce529155f1bcb45a01e566687b4fd4eb xml2rfc-3.5.0.tar.gz.asc > $ > > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev --------------2565B941D4AE69F33F6DE4AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Daniel -

You'll have seen that 3.6.0 was just released, and this comment has not yet been addressed.

It's on the list to deal with. I wanted to make sure you knew this wasn't being ignored.

RjS

On 2/18/21 3:40 PM, Daniel Kahn Gillmor wrote:

Hi folks--

I'm looking at the latest xml2rfc tarball and its OpenPGP signature:

https://files.pythonhosted.org/packages/c0/81/21281e78fd2afb8f5dfcb92b78c9dcd621081277304e0f25df0ee7c89c64/xml2rfc-3.5.0.tar.gz
https://files.pythonhosted.org/packages/c0/81/21281e78fd2afb8f5dfcb92b78c9dcd621081277304e0f25df0ee7c89c64/xml2rfc-3.5.0.tar.gz.asc

The signature file (the *.asc) is made using SHA-1 for the signature:

    $ pgpdump  < xml2rfc-3.5.0.tar.gz.asc 
    Old: Signature Packet(tag 2)(540 bytes)
            Ver 4 - new
            Sig type - Signature of a binary document(0x00).
            Pub alg - RSA Encrypt or Sign(pub 1)
            Hash alg - SHA1(hash 2)
            Hashed Sub: signature creation time(sub 2)(4 bytes)
                    Time - Wed Nov 18 05:20:56 EST 2020
            Sub: issuer key ID(sub 16)(8 bytes)
                    Key ID - 0x4E9B574B8FBB171A
            Hash left 2 bytes - d2 9f 
            RSA m^d mod n(4094 bits) - ...
                    -> PKCS-1
    $

Signatures using SHA-1 have been deprecated for over a decade now.  No
modern tool should generate them.

>From the Version: comment in the .asc file, it looks to me like these
signatures are being generated from the old, deprecated "classic"
version of GnuPG ("Version: GnuPG v1").

Henrik (or whoever else might make a future release of xml2rfc), is
there something blocking you from updating to a more modern OpenPGP
implementation for making these signatures?  The GnuPG 2.2.x series
("modern") should make signatures with sha256 (or better) by default, as
should pretty much any other OpenPGP implementation (sequoia,
openpgp.js, gopenpgp, rnp, pgpainless, etc).  There's probably also a
way to coax better-than-SHA-1 signatures out of GnuPG 1.x as well, but
that toolkit is unable to deal with modern tooling like ECC keys so i
recommend upgrading anyway.

The irony here is that i'm trying to work on the RFC for OpenPGP itself
to refresh the cryptographic requirements in that standard, and i'm
working with modern tooling that deprecates SHA-1 signatures
appropriately; and to update the xml2rfc package i want to check the
OpenPGP signature, etc.  a nice little loop!

I figure it's probably neither possible nor advisable to re-issue a
signature over xml2rfc version 3.5.0, but if you can line it up so that
signatures of future releases avoid using SHA1, that'd be great.

               --dkg

PS The files i've fetched from the above URLs have this content (just in
   case anyone wants to replicate, they can confirm that they're getting
   the same thing):

$ sha256sum *
3ec836a9545f549707a8c8176038160185b9d08c1dd80304a906527da21bff68  xml2rfc-3.5.0.tar.gz
ef652fda6c1f7b63f22765e7df48d627ce529155f1bcb45a01e566687b4fd4eb  xml2rfc-3.5.0.tar.gz.asc
$

_______________________________________________
xml2rfc-dev mailing list
xml2rfc-dev@ietf.org
https://www.ietf.org/mailman/listinfo/xml2rfc-dev

--------------2565B941D4AE69F33F6DE4AE-- From nobody Wed Mar 17 14:02:27 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016C13A14CC for ; Wed, 17 Mar 2021 14:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=Dt1n7eYF; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=YPjAo3nD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUyRdRBq5uTv for ; Wed, 17 Mar 2021 14:02:24 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2B83A14CB for ; Wed, 17 Mar 2021 14:02:24 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1616014940; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=4XUfq3qDPZO0xqlUErizJTb7oSV6gS80EzrtJLqQ9Vc=; b=Dt1n7eYFuW+kUnmPj1xxQt3HwP++z/hdrxiZ/eRP4lQ02bpLbwk4GAuK9M8ul+9BH1DT4 l0BurlWmEYYTKMNBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1616014940; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=4XUfq3qDPZO0xqlUErizJTb7oSV6gS80EzrtJLqQ9Vc=; b=YPjAo3nDD6J+KrldWDXphkfKrufX++DWhyULe9y1f5VPknO1c363UACXGsGyZh1Qguc3z 29UyoD+M93y01O5MUGkRLh7JRsPSTRDmHnIOF7iuF0Kt0lFcBvTqLDJ8LkiLke98L12UPLx GFDSzRR4/fgikMuW+C1dtVRc1VqMo5KZgXtvwfYUybRxdxVLp6y4Ep5g4cHflVMm+j6kSqD 224BU1EZcuVhid3tUyG+Me+vt4gmhaUmAoqCM61erBbuGQmX6DwQfV8lpSz14LB/5aDmHb9 seyWoCZR5X/oHdzCN8W6TFBzNU4V7AvH0CqlTRRXVsB4SM67zH8dfFUMwVqA== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 4360DF9A5; Wed, 17 Mar 2021 17:02:20 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id AC58A20415; Wed, 17 Mar 2021 17:02:17 -0400 (EDT) From: Daniel Kahn Gillmor To: Robert Sparks , xml2rfc-dev@ietf.org In-Reply-To: References: <87y2flrr5y.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Wed, 17 Mar 2021 17:02:16 -0400 Message-ID: <87v99p5w9z.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [xml2rfc-dev] cryptographic signatures over xml2rfc releases should not be made with SHA1 X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 21:02:26 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Robert-- On Wed 2021-03-17 14:26:54 -0500, Robert Sparks wrote: > You'll have seen that 3.6.0 was just released, and this comment has not=20 > yet been addressed. > > It's on the list to deal with. I wanted to make sure you knew this=20 > wasn't being ignored. Thanks for the heads-up, and for the stated intent to fix the issue. Let me know if there's anything i can do to help the process of fixing this, including by private mail if you like. As one of the debian maintainers of GnuPG, and as a co-chair of the OpenPGP WG, i can hopefully give reasonably useful advice in multiple domains: practical tooling guidance, system integration advice, theoretical explanations, and protocol level detail. lemme know if you need any of it. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYFJuWQAKCRA+nXFzcd5W XJLZAP9gUZoRjyK0a1MTOty2bx+uU/3kVBP5/1HW4D7+0roWagEAvm+jHtHcIacO HqXR+/cEHUJr2BR3rwBhXiAK5+n/AQ0= =b/8J -----END PGP SIGNATURE----- --=-=-=--