From kloecker at kde.org Fri Aug 1 09:48:37 2025 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Fri, 01 Aug 2025 09:48:37 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: References: <26123D2E-D6A5-412A-BC9F-5E14FDCF170C@andrewg.com> Message-ID: <5706176.rdbgypaU67@daneel> On Donnerstag, 31. Juli 2025 23:28:51 Mitteleurop?ische Sommerzeit JL wrote: > well it does compress, however you can't compress it on the imap server, Pardon my ignorance, but why can't the IMAP server store your emails compressed? Maybe you should complain to the operator of the IMAP server if, in your opinion, they are wasting storage space. Or complain to its authors if you are operate the server yourself. Given the insane growth of email headers it would actually make sense that the IMAP server used compression. Taking your message (as it is stored on my IMAP server) as example: Size of the header: 12,315 bytes Size of the body: 8,556 bytes. By the way, why is the body of your message base64 encoded? Was is re-encoded in flight or did your Thunderbird send your unsigned plain text message base64 encoded? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From noloader at gmail.com Fri Aug 1 12:40:43 2025 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 1 Aug 2025 06:40:43 -0400 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <5706176.rdbgypaU67@daneel> References: <26123D2E-D6A5-412A-BC9F-5E14FDCF170C@andrewg.com> <5706176.rdbgypaU67@daneel> Message-ID: On Fri, Aug 1, 2025 at 3:49?AM Ingo Kl?cker wrote: > On Donnerstag, 31. Juli 2025 23:28:51 Mitteleurop?ische Sommerzeit JL > wrote: > > well it does compress, however you can't compress it on the imap server, > > Pardon my ignorance, but why can't the IMAP server store your emails > compressed? Maybe you should complain to the operator of the IMAP server > if, > in your opinion, they are wasting storage space. Or complain to its > authors if > you are operate the server yourself. > I would hazard a guess that it relates to searching and sorting. IMAP supports the SEARCH command. The SEARCH command allows searching on the server based on keywords/free text, date ranges, and header fields. > Given the insane growth of email headers it would actually make sense that > the > IMAP server used compression. Taking your message (as it is stored on my > IMAP > server) as example: > Size of the header: 12,315 bytes > Size of the body: 8,556 bytes. > > By the way, why is the body of your message base64 encoded? Was is > re-encoded > in flight or did your Thunderbird send your unsigned plain text message > base64 > encoded? > Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Aug 1 17:34:01 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 01 Aug 2025 17:34:01 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: References: <87ms8lsuau.fsf@jacob.g10code.de> <67e83ba3-46b3-4268-8235-68ae9a8b947b@dolce-energy.com> <26123D2E-D6A5-412A-BC9F-5E14FDCF170C@andrewg.com> Message-ID: <20250801153401.ikqqW6Hr@steffen%sdaoden.eu> JL wrote in : It also depends you know. Ie normally MUAs then "classify" whatever they create a MIME Part for, and this classification may use some ratio of XY characters to choose the one or the other transfer encoding. See also libmagic(1); my MUA differs to that for example (last i looked) as we also wave through \v/\x0B/VT and \f=\x0C=NP, and we ignore ESC, ie, may use quoted-printable not base64. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From devm23k73ju29h3r at dolce-energy.com Fri Aug 1 23:07:08 2025 From: devm23k73ju29h3r at dolce-energy.com (JL) Date: Fri, 1 Aug 2025 23:07:08 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: References: <26123D2E-D6A5-412A-BC9F-5E14FDCF170C@andrewg.com> <5706176.rdbgypaU67@daneel> Message-ID: <3777908a-f8c1-4a4b-8874-774ef0fdfee3@dolce-energy.com> Le 01/08/2025 ? 12:40, Jeffrey Walton via Gnupg-devel a ?crit?: > > > On Fri, Aug 1, 2025 at 3:49?AM Ingo Kl?cker wrote: > > On Donnerstag, 31. Juli 2025 23:28:51 Mitteleurop?ische Sommerzeit > JL wrote: > > well it does compress, however you can't compress it on the imap > server, > > Pardon my ignorance, but why can't the IMAP server store your emails > compressed? Maybe you should complain to the operator of the IMAP > server if, > in your opinion, they are wasting storage space. Or complain to > its authors if > you are operate the server yourself. > > > I would hazard a guess that it relates to searching and sorting. IMAP > supports the SEARCH command. The SEARCH command allows searching on > the server based on keywords/free text, date ranges, and header fields. this is server side... doesn't apply to local storage, you might want to keep things on server, I don't. Even if it's usefull, a server is a good target for hackers, even google, apple, facebook, got hacked, they often assure that "no personal emails were gatered" we just have their words, no one beside them know the truth... since emails on servers are not cyphered, all the important data is freely accessible. Beside, there is mail quota... so you can't store everything on imap > Given the insane growth of email headers it would actually make > sense that the > IMAP server used compression. Taking your message (as it is stored > on my IMAP > server) as example: > Size of the header: 12,315 bytes > Size of the body: 8,556 bytes. > > By the way, why is the body of your message base64 encoded? Was is > re-encoded > in flight or did your Thunderbird send your unsigned plain text > message base64 > encoded? > Because it's the safe fallback, and rather than make the things evolve, all email client prefer the safe way : the one that will works even on 30 years ago server/client. 8bit mime isn't perfect because it didn't defined way to handle the crlf in binary or because it didn't enforced that the buffer has to be filled. Smtp defined a way to prevent end of transmission if the message contains . but I didn't saw some escape mecanism for 8 bit mime... which means that it's up to the client to handle this case (even if in binary data, it should occurs not so often) don?t know if there is some rfc that define way to escape so that they could be dropped by client (for example in data recoded into \\ so that can be dropped) anyway this is only a smtp issue, or the server should handle rfc3030 "BDAT" command for example that is cleaner... beside the smtp consideration, on IMAP side, the data can be accessed in binary, and mime has a "Content-Transfer-Encoding" binary... so from the client point of view, the received message could be "decoded" on the fly and stored with decoded value... some server might transform the data (because one server on the way don't handle BDAT for exemple) but the end server could re-code it as binary... instead of keeping it base64...? The problem is that client often "write the data to file" and then "send the file through smtp" so not knowing if the smtp server can handle the BDAT... so the safe way, if you don't know the server, is to encode everything in base64... so the problem is multiple : * user email client : don't handle well binary.... and don?t encode data "on the fly" when talking with the smtp server.... * SMTP : a server might encode to base64 because the other server don't handle BDAT transmission, if there are relay server, they should reverse it back to binary.... and the final server should re-format the data... best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From devm23k73ju29h3r at dolce-energy.com Sat Aug 2 00:17:04 2025 From: devm23k73ju29h3r at dolce-energy.com (JL) Date: Sat, 2 Aug 2025 00:17:04 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <5706176.rdbgypaU67@daneel> References: <26123D2E-D6A5-412A-BC9F-5E14FDCF170C@andrewg.com> <5706176.rdbgypaU67@daneel> Message-ID: <66506f22-1b80-4f6b-9bc4-ae381593e62e@dolce-energy.com> Le 01/08/2025 ? 09:48, Ingo Kl?cker a ?crit?: > On Donnerstag, 31. Juli 2025 23:28:51 Mitteleurop?ische Sommerzeit JL wrote: >> well it does compress, however you can't compress it on the imap server, > Pardon my ignorance, but why can't the IMAP server store your emails > compressed? Maybe you should complain to the operator of the IMAP server if, > in your opinion, they are wasting storage space. Or complain to its authors if > you are operate the server yourself. you have nothing to be pardonned, I'm not the most up-to-date and rather ignorant on the matter... well, they might, but it don't means your quota will (and then that you'll benefit) they surely do it, storing on filesystem with transparent compression... But they can't compress it serverside without rewriting the message (they have to keep the mime file format so that the client can read them... a smart server would have received the data, and decoded once for all, like this, it'll have been network efficient and storage efficient, but this introduce the issue of PGP signing... since the message is "modified" and don't know how to scope with this matter... is it possible to "sign" each part before encoding? (like a checksum file containing all the checksum of every attached file for example) if it's assumed that the message MUST not be altered, you have to go the safe way : encode everything in 7bit ASCII if the signing can be done "part by part in binary" then there is nothing to worry about "re-formating" and a SMTP server can choose to send it binary (if BINARYMIME and BDAT is supported) or re-code it.... just guessing, how a smtp server will handle if it received a BINARYMIME and have to talk to a non BINARYMIME server, what will?they do? enclose the whole message into a Content-Type: message/rfc822; boundary="------------AF0V9AuRuaNTRxYbEuAis34i"; Content-Transfer-Encoding: base64 XXXXXXXXXXXX XXXXXXXXXXXX ------------AF0V9AuRuaNTRxYbEuAis34i" ? best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From devm23k73ju29h3r at dolce-energy.com Sat Aug 2 13:05:07 2025 From: devm23k73ju29h3r at dolce-energy.com (JL) Date: Sat, 2 Aug 2025 13:05:07 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <66506f22-1b80-4f6b-9bc4-ae381593e62e@dolce-energy.com> References: <26123D2E-D6A5-412A-BC9F-5E14FDCF170C@andrewg.com> <5706176.rdbgypaU67@daneel> <66506f22-1b80-4f6b-9bc4-ae381593e62e@dolce-energy.com> Message-ID: <03a63bbe-d4eb-4572-8728-78d23c5e6f95@dolce-energy.com> > ?a smart server would have received the data, and decoded once for > all, like this, it'll have been network efficient and storage > efficient, but this introduce the issue of PGP signing... since the > message is "modified" and don't know how to scope with this matter... > is it possible to "sign" each part before encoding? (like a checksum > file containing all the checksum of every attached file for example) > > if it's assumed that the message MUST not be altered, you have to go > the safe way : encode everything in 7bit ASCII > > if the signing can be done "part by part in binary" then there is > nothing to worry about "re-formating" and a SMTP server can choose to > send it binary (if BINARYMIME and BDAT is supported) or re-code it.... > replying to myself after reading the * rfc4880 " OpenPGP Message Format" * rfc3156 "MIME Security with OpenPGP" the latter state that, because the message can be reformated, ? ?However, many existing mail gateways will detect if the next ? ?hop does not support MIME or 8-bit data and perform conversion to ? ?either Quoted-Printable or Base64.? This presents serious problems ? ?for multipart/signed, in particular, where the signature is ? ?invalidated when such an operation occurs.? For this reason all data ? ?signed according to this protocol MUST be constrained to 7 bits (8- ? ?bit data MUST be encoded using either Quoted-Printable or Base64). that's too bad, since in fact the "format" is enforced before signing, while they could have chosen the opposite : enforcing all binary fike to be presented into binary format in the mime message, and signing versification should only be performed once restored to original format.... and in fact a false issue... the signature won't be invalidated if the presentation change, since the presentation shall not alter the original content and is reversible... so it just needed to force the orginal format to create the message with binary data when binary data, 8bit strings when 8bits strings, eg removing the formating process. On reception, the receiver remove the formating, going back to binary for things that are binary, and validate the unformatted content... it would have been compatible with other RFC effort to allow binary data to go through the smtp protocol... really, too bad... -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Sat Aug 2 15:04:41 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 2 Aug 2025 14:04:41 +0100 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <03a63bbe-d4eb-4572-8728-78d23c5e6f95@dolce-energy.com> References: <03a63bbe-d4eb-4572-8728-78d23c5e6f95@dolce-energy.com> Message-ID: <9958C9B4-569D-4925-9119-4EDC1E99F432@andrewg.com> On 2 Aug 2025, at 12:06, JL wrote: > > that's too bad, since in fact the "format" is enforced before signing, while they could have chosen the opposite : enforcing all binary fike to be presented into binary format in the mime message, and signing versification should only be performed once restored to original format.... I think you have misread the spec because that?s already what it requires. Signing is performed before encoding to 7-bit safe format, and verification after decoding. The only time normalisation is performed before signing is with 0x01 text document signatures, when line endings are converted to wire format. This is increasingly a historical curiosity though, and is unnecessary if you are using base64. A From andrewg at andrewg.com Sat Aug 2 15:31:49 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 2 Aug 2025 14:31:49 +0100 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <9958C9B4-569D-4925-9119-4EDC1E99F432@andrewg.com> References: <9958C9B4-569D-4925-9119-4EDC1E99F432@andrewg.com> Message-ID: On 2 Aug 2025, at 14:06, Andrew Gallagher wrote: > > ?On 2 Aug 2025, at 12:06, JL wrote: >> >> that's too bad, since in fact the "format" is enforced before signing, while they could have chosen the opposite : enforcing all binary fike to be presented into binary format in the mime message, and signing versification should only be performed once restored to original format.... > > I think you have misread the spec because that?s already what it requires. Signing is performed before encoding to 7-bit safe format, and verification after decoding. The only time normalisation is performed before signing is with 0x01 text document signatures, when line endings are converted to wire format. This is increasingly a historical curiosity though, and is unnecessary if you are using base64. OK, my turn to reply to myself. Sorry, *I* misread *your* message. :-( The above comment doesn?t apply to your scenario. Yes, base64 is used because it is relatively immune to mangling by MTAs in transit (although not perfectly so). And while you can transmit an entire signed message as a base64 blob, it?s more common to sign over the mime structure, which may have subparts, and so 7-bit safe encoding can happen before the signing step. It was specified this way so that naive clients could still process the signed-over data and display it without having to understand the details of openpgp. Sorry for the confusion. A From collin.funk1 at gmail.com Wed Aug 6 06:16:14 2025 From: collin.funk1 at gmail.com (Collin Funk) Date: Tue, 5 Aug 2025 21:16:14 -0700 Subject: [PATCH gnupg] Fix typos in messages. Message-ID: <2e3bb911f4afcd9f64043a1c9a189bfc4fc31210.1754453772.git.collin.funk1@gmail.com> * agent/gpg-agent.c (map_supervised_sockets): Fix spelling of --deprecated-supervised. * g10/gpg.c (main): Fix spelling of --quick-set-expire. * scd/command.c (hlp_checkpin): Fix spelling of modifying. * g10/decrypt.c (decrypt_message): Fix spelling of mutually. -- Signed-off-by: Collin Funk --- agent/gpg-agent.c | 2 +- g10/decrypt.c | 2 +- g10/gpg.c | 2 +- scd/command.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index ae1295977..3dcb6281b 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -782,7 +782,7 @@ map_supervised_sockets (gnupg_fd_t *r_fd, fd_count); if (fstat (3, &statbuf) == -1 && errno ==EBADF) log_fatal ("file descriptor 3 must be valid in" - " --depreacted-supervised mode" + " --deprecated-supervised mode" " if LISTEN_FDNAMES is not set\n"); *r_fd = 3; socket_name = gnupg_get_socket_name (3); diff --git a/g10/decrypt.c b/g10/decrypt.c index e232c188f..644bf2eba 100644 --- a/g10/decrypt.c +++ b/g10/decrypt.c @@ -107,7 +107,7 @@ decrypt_message (ctrl_t ctrl, const char *filename, strlist_t remusr) opt.outfile = NULL; if (ctrl->modify_recipients && (err || !dek) ) - log_error (_("modifiying the recipients is not possible: %s\n"), + log_error (_("modifying the recipients is not possible: %s\n"), err? gpg_strerror (err) : _("decryption failed")); else if (ctrl->modify_recipients) { diff --git a/g10/gpg.c b/g10/gpg.c index d0f575d7e..b2ca71cb8 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -5016,7 +5016,7 @@ main (int argc, char **argv) const char *x_fpr, *x_expire; if (argc < 2) - wrong_args ("--quick-set-exipre FINGERPRINT EXPIRE [SUBKEY-FPRS]"); + wrong_args ("--quick-set-expire FINGERPRINT EXPIRE [SUBKEY-FPRS]"); x_fpr = *argv++; argc--; x_expire = *argv++; argc--; keyedit_quick_set_expire (ctrl, x_fpr, x_expire, argv); diff --git a/scd/command.c b/scd/command.c index 792a347b4..b0a639dde 100644 --- a/scd/command.c +++ b/scd/command.c @@ -1766,7 +1766,7 @@ static const char hlp_checkpin[] = "\n" " For a definitive list, see the implementation in app-nks.c.\n" " Note that we call a PW2.* PIN a \"PUK\" despite that since TCOS\n" - " 3.0 they are technically alternative PINs used to mutally\n" + " 3.0 they are technically alternative PINs used to mutually\n" " unblock each other.\n" "\n" "For PKCS#15:\n" -- 2.50.1 From pschwabauer at intevation.de Thu Aug 7 14:08:28 2025 From: pschwabauer at intevation.de (Paul Schwabauer) Date: Thu, 7 Aug 2025 14:08:28 +0200 Subject: gpgmepy issues and issue tracking Message-ID: Currently, there is no dedicated tag for the gpgmepy project in the official issue tracker, only for gpgme. Are there any objections to adding a gpgmepy tag to the tracker and using it to keep track of related issues? If there are concerns, we?ll need to identify an alternative issue tracking system for this project. In connection with this, I?ve compiled a list of issues that we need to track: 1. Beta Version Numbering When building gpgmepy, the version generated is 2.0.1, without a beta suffix. I followed the documented process for incrementing the version, but unlike with 2.0.0, the beta version is not being generated based on the number of commits. This complicates pushing out beta releases that include minor changes and require user feedback. ? - Is this the expected behavior? ? - Does a different tag need to be used? ? - Do the build scripts require changes? 2. Link to Official Release Tarball The official download page at https://gnupg.org/download/index.html currently does not link to the gpgmepy release tarball, it only links to GPGME. The actual release is located at https://gnupg.org/ftp/gcrypt/gpgmepy/, but this location is not easily discoverable. We should consider updating the main download page to include a link to the gpgmepy release. 3. Documentation and Example Scripts on PyPI The release tarball includes several Python examples, which are no longer (correctly) included in the source distribution package on PyPI. However, this makes it difficult for users to discover or access them. We need to discuss: ? - Where to host or link these example scripts ? - Whether to include references to them in the PyPI package description or elsewhere Let me know your thoughts on the issue tracker update, and any suggestions for resolving the points above. From Andreas.Stieger at gmx.de Thu Aug 7 14:36:11 2025 From: Andreas.Stieger at gmx.de (Andreas Stieger) Date: Thu, 7 Aug 2025 14:36:11 +0200 Subject: gpgmepy issues and issue tracking In-Reply-To: References: Message-ID: On 2025-08-07 14:08, Paul Schwabauer via Gnupg-devel wrote: > 2. Link to Official Release Tarball > > The official download page at https://gnupg.org/download/index.html > currently does not link to the gpgmepy release tarball, it only links > to GPGME. The actual release is located at > https://gnupg.org/ftp/gcrypt/gpgmepy/, but this location is not easily > discoverable. > > We should consider updating the main download page to include a link > to the gpgmepy release. Code for that is at?https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=summary Andreas From pschwabauer at intevation.de Thu Aug 7 17:24:31 2025 From: pschwabauer at intevation.de (Paul Schwabauer) Date: Thu, 7 Aug 2025 17:24:31 +0200 Subject: gpgmepy issues and issue tracking In-Reply-To: References: Message-ID: <84e02017-82c2-461f-adbb-03c2e89a75f3@intevation.de> > Currently, there is no dedicated tag for the gpgmepy project in the > official issue tracker, only for gpgme. Are there any objections to > adding a gpgmepy tag to the tracker and using it to keep track of > related issues? If there are concerns, we?ll need to identify an > alternative issue tracking system for this project. I just checked, I don't have permissions to create a project in dev.gnupg.org. From kloecker at kde.org Fri Aug 8 12:40:25 2025 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Fri, 08 Aug 2025 12:40:25 +0200 Subject: gpgmepy issues and issue tracking In-Reply-To: References: Message-ID: <5705404.rdbgypaU67@daneel> On Donnerstag, 7. August 2025 14:08:28 Mitteleurop?ische Sommerzeit Paul Schwabauer via Gnupg-devel wrote: > 1. Beta Version Numbering > > When building gpgmepy, the version generated is 2.0.1, without a beta > suffix. I followed the documented process for incrementing the version, > but unlike with 2.0.0, the beta version is not being generated based on > the number of commits. This complicates pushing out beta releases that > include minor changes and require user feedback. > > - Does a different tag need to be used? Yes. You have to create an annotated tag. Ideally, you create a GPG-signed tag. > 3. Documentation and Example Scripts on PyPI > > The release tarball includes several Python examples, which are no > longer (correctly) included in the source distribution package on PyPI. > However, this makes it difficult for users to discover or access them. > > We need to discuss: > > - Where to host or link these example scripts > > - Whether to include references to them in the PyPI package > description or elsewhere I don't know what's common in the Python world. I would look for examples in the Examples section of the official documentation. Given that there doesn't seem to be documentation published anywhere linking them from the description makes sense. The scripts are hosted in the repo. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From pikolasikolatest2 at gmail.com Fri Aug 8 18:54:34 2025 From: pikolasikolatest2 at gmail.com (walid falcon) Date: Fri, 8 Aug 2025 17:54:34 +0100 Subject: =?UTF-8?B?2LTZh9in2K/YqSDYp9mE2KPYqNmI2Kkg2YHZiiDYp9mE2YXYutix2Kg=?= Message-ID: ?? ?? ????? ?????? ??? ????? ?????? ??????? ????? ????? ????? ?? ???? ?????? ??????? https://www.targir.com/2025/04/blog-post_14.html ??????? ????? ???????? ????? ?????? ?????????? ????????? ???????? ??? ?? ?? ????? ?????? ?? ??????? ????? ?????? ????? ??????? ???? ????? ??? ??? ?????? ?????? ??????? ??????? ??? ????? ?????? ?????????? ?? ??? ??? ???? ??? ???? ???? ?? ????? ????. ????? ??? ??????? ????? ?? ????????? ???????? ???? ???? ??? ????? ?????? ???????. ??????? ???? ?????? ??????? ????? ?????? 1. ??????? ??? ???????? ?? ?????? ??????? ????? ???? ??? ???? ???? ?????? ?? ?? ??????? ???? ??????? ?? ???? ?????? ???????? ????? ???? ??? ??? ???? ?????? ??? ????? ??????. 2. ????? ????? ?? ???? ??? ???? ?? ????? ??? ???? ????? ?????? ??? ???????? ????? ??? ??????? ?????? ??????? ???????. ??????? ?????? ??? ????? ?????? ????: ??? ???? ???? ??????? ????? ??? ???? ?? ??? ??? ????? ????? ??? ??? ??????? ?????????? ???? ??? ???? ??? ??? ????? ?? ????? ???? ?? ??? ????? ??? ????? ?????? ??????. ??????: ??????? ???????? ???? ?? ????? ??????? ??????? ??? ???????? ????? ?????? (?? ????) ????? ???? ??????? ????? ?????? ????? ?? ??????? ???? ????? ???? ?????? ????? ????? ?????? pdf ???? ??? ??????? ??????????? ????? ????? ????? ?????? PDF ???? ???????? ??? ?? ??????? ?????? ?? ??? ??? ??? ??? ?????? ???? ??????? ?????? ?????? ??????? ?????? ?????. ??????? ??????? ??? ????? ?????? ?? ???? ????? ??? ????? ?????? ??????????? ??? ??????? ??? ?????? ?????? ?????? ???? ???????. ?? ?? ??? ?????? ??? ????? ??????? ?? ????? ????? ??? ??? ???????? ???? ???? ?? ?????? ??? ??? ??? ????? ????? ??? ????? ?????. ??? ??? ????? ?????? ???? ???????? ????????? ?????? ?? ????? ??? ??? ?????? ??? ????? ?????? ???? ???????? ????????? ?????? ???? ???? ???? ??????? ???: 1. ??????? ?????? ?????? ????? ?????? ?? ????? ?? ??? ??????? ????????? ????? ????? ???? ??? ??????? ????? ??????? ??? ?? ????? ??: ??????? ???????? ???????? ????? ????? ?? ????? ??????? ????? ???? ?????? ??????? ?????? ?????????? 2. ??????? ??????? ????? ????? ?? ????? ??? ???? ????? ???? ????? ??? ??????? ?? ????? ??????? ??? ????? ?? ????? ?????? ?? ????? ?????? ?????????? ??? ?? ???? ????? ?????? ?????? ?? ??? ??????? ????????? ??????. ????? ?????? ?????? ?? ??? ??????? ?? ????? ????? ?????? ?????? ???? ??? ????? ?? ????? ?????? ?? ???? ?? ??? ??????? ????????. ???? ????? ??????? ?????? ??????? ??????? ???????? ??????? ?????? : ? ????? ??????? ? ? ?????? ??????? ??????? ?????? : ? ????? ????? ???? ? ? ?????? ??????? . ??????? ??????? ??????? ??????? ???????? ??????? ???????? ??????? ???? ????? ???? ????? ??????? ??????? ?????? ?????? ??????? ???????? ??????? ???? ????? ???? ????? ?? ???? ???? ?????? ??? ?????? ????? ?????? ???? ??????? ????? ?????? ???????? ???????? ???? ????????? (??????? ???????) ????? ?????? ???????? ????????_????? ????? ????? ????? ?? ???? ?????? ??????? ????? ????? ?????? ??????? ????? ?????? ??: [??? ???????] ??? ?????: [????? ???????] ??? ??????: [????? ???????] ???? ????? ??????? ??? ?????? ?????: ????? ??????: [????? ?????? ????] ??? ????? ??????? ???????: [??? CIN] ????? ????? ????????: [????? ????? ????? ????] ??????? ??????: [????? ???????] ??????: [?????? ???????] ?????? ????? ???? ?????? ???? ??????? ??????????? ??? ???: ?? ????? (?) ?????? (?): [??? ?????/?] ??????? (?) ??????: [????? ???????] ??: [???? ???????] ??(??) ????/????? ?????????(?)? ??? ????(?) ????? ????? ????? ????? ???? ???? ??????: [??? ????]? ???????? ??????: [????? ????? ????]? ???????? ???? ????? ??????? ???????: [??? CIN ????]. ?????? ???? ????????? ????????? ???????? ???? ??? ?????/?? ????? ?? ??????? ??????? ????? ??? ????? ???? ??? ????? ??? ??????? ?? ??????? ?? ?????? ???????. ??????? ????? ??????: _____________________ ???????: ___________________________ ???????: ____ / ____ / ________ ??????? : ????? ??? ??????? ???????? ??????? ??: ???? ??????? ???????? ????? ??????? ????? ???????? ??????. ?????? ??? ????? ??? ??????? ?????????? (??? ???? ??????) ???? ??? ??? ???????? ??? ????? ????? ?? ??? ??? ????. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam at gentoo.org Sun Aug 10 05:20:28 2025 From: sam at gentoo.org (Sam James) Date: Sun, 10 Aug 2025 03:20:28 -0000 Subject: DCO Message-ID: <0A0826C4-2336-437F-A815-DE5BF69AF8EB@gentoo.org> GPGME Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GPGME project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Sam James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 358 bytes Desc: Message signed with OpenPGP URL: From sam at gentoo.org Sun Aug 10 04:36:11 2025 From: sam at gentoo.org (Sam James) Date: Sun, 10 Aug 2025 03:36:11 +0100 Subject: [gpa PATCH] Fix incorrect callback arguments Message-ID: <1bce45d716ba687e794421db6ff061673d204e9d.1754793371.git.sam@gentoo.org> Some users reported a crash downstream in Gentoo with g_type_check_is_value_type getting a garbage type. This turns out to be because 95e07080a2a08196cafb05b69345ea1d629424b1 replaced the types (and argument counts) incorrectly. Fix that by adding to gpa_marshal.list to create custom marshal types and use those instead, and fix the argument count. Bug: https://bugs.gentoo.org/957196 Fixes: 95e07080a2a08196cafb05b69345ea1d629424b1 Signed-off-by: Sam James --- Note that I've sent a DCO before in August 2022 but I don't spot it in the archives at a glance, so sent it again just now. src/gpa-marshal.list | 2 ++ src/gpacontext.c | 5 +++-- src/gpakeyexpireop.c | 3 ++- 3 files changed, 7 insertions(+), 3 deletions(-) diff --git a/src/gpa-marshal.list b/src/gpa-marshal.list index 081ce17..941257d 100644 --- a/src/gpa-marshal.list +++ b/src/gpa-marshal.list @@ -1 +1,3 @@ INT:STRING,STRING +VOID:INT,INT +VOID:POINTER,POINTER diff --git a/src/gpacontext.c b/src/gpacontext.c index 91bd85f..31301c0 100644 --- a/src/gpacontext.c +++ b/src/gpacontext.c @@ -25,6 +25,7 @@ #include "gpa.h" #include "gpgmetools.h" #include "gpacontext.h" +#include "gpa-marshal.h" /* GObject type functions */ @@ -145,9 +146,9 @@ gpa_context_class_init (GpaContextClass *klass) G_SIGNAL_RUN_FIRST, G_STRUCT_OFFSET (GpaContextClass, progress), NULL, NULL, - g_cclosure_marshal_VOID__INT, + gpa_marshal_VOID__INT_INT, G_TYPE_NONE, 2, - G_TYPE_INT); + G_TYPE_INT, G_TYPE_INT); } static void diff --git a/src/gpakeyexpireop.c b/src/gpakeyexpireop.c index a489087..25e489e 100644 --- a/src/gpakeyexpireop.c +++ b/src/gpakeyexpireop.c @@ -31,6 +31,7 @@ #endif #include "gpa.h" +#include "gpa-marshal.h" #include "gpakeyexpireop.h" #include "expirydlg.h" #include "gpgmeedit.h" @@ -114,7 +115,7 @@ gpa_key_expire_operation_class_init (GpaKeyExpireOperationClass *klass) G_SIGNAL_RUN_FIRST, G_STRUCT_OFFSET (GpaKeyExpireOperationClass, new_expiration), NULL, NULL, - g_cclosure_marshal_VOID__POINTER, + gpa_marshal_VOID__POINTER_POINTER, G_TYPE_NONE, 2, G_TYPE_POINTER, G_TYPE_POINTER); -- 2.50.1 From sam at gentoo.org Sun Aug 10 08:22:34 2025 From: sam at gentoo.org (Sam James) Date: Sun, 10 Aug 2025 07:22:34 +0100 Subject: [gpa PATCH] Fix incorrect callback arguments In-Reply-To: <1bce45d716ba687e794421db6ff061673d204e9d.1754793371.git.sam@gentoo.org> References: <1bce45d716ba687e794421db6ff061673d204e9d.1754793371.git.sam@gentoo.org> Message-ID: <87ldnrvgph.fsf@gentoo.org> Sam James writes: > Some users reported a crash downstream in Gentoo with g_type_check_is_value_type > getting a garbage type. This turns out to be because > 95e07080a2a08196cafb05b69345ea1d629424b1 replaced the types (and argument > counts) incorrectly. > > Fix that by adding to gpa_marshal.list to create custom marshal types > and use those instead, and fix the argument count. > > Bug: https://bugs.gentoo.org/957196 > Fixes: 95e07080a2a08196cafb05b69345ea1d629424b1 > Signed-off-by: Sam James > --- > Note that I've sent a DCO before in August 2022 but I don't spot it in > the archives at a glance, so sent it again just now. > +cc Andreas, sorry I forgot earlier. > src/gpa-marshal.list | 2 ++ > src/gpacontext.c | 5 +++-- > src/gpakeyexpireop.c | 3 ++- > 3 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/src/gpa-marshal.list b/src/gpa-marshal.list > index 081ce17..941257d 100644 > --- a/src/gpa-marshal.list > +++ b/src/gpa-marshal.list > @@ -1 +1,3 @@ > INT:STRING,STRING > +VOID:INT,INT > +VOID:POINTER,POINTER > diff --git a/src/gpacontext.c b/src/gpacontext.c > index 91bd85f..31301c0 100644 > --- a/src/gpacontext.c > +++ b/src/gpacontext.c > @@ -25,6 +25,7 @@ > #include "gpa.h" > #include "gpgmetools.h" > #include "gpacontext.h" > +#include "gpa-marshal.h" > > /* GObject type functions */ > > @@ -145,9 +146,9 @@ gpa_context_class_init (GpaContextClass *klass) > G_SIGNAL_RUN_FIRST, > G_STRUCT_OFFSET (GpaContextClass, progress), > NULL, NULL, > - g_cclosure_marshal_VOID__INT, > + gpa_marshal_VOID__INT_INT, > G_TYPE_NONE, 2, > - G_TYPE_INT); > + G_TYPE_INT, G_TYPE_INT); > } > > static void > diff --git a/src/gpakeyexpireop.c b/src/gpakeyexpireop.c > index a489087..25e489e 100644 > --- a/src/gpakeyexpireop.c > +++ b/src/gpakeyexpireop.c > @@ -31,6 +31,7 @@ > #endif > > #include "gpa.h" > +#include "gpa-marshal.h" > #include "gpakeyexpireop.h" > #include "expirydlg.h" > #include "gpgmeedit.h" > @@ -114,7 +115,7 @@ gpa_key_expire_operation_class_init (GpaKeyExpireOperationClass *klass) > G_SIGNAL_RUN_FIRST, > G_STRUCT_OFFSET (GpaKeyExpireOperationClass, new_expiration), > NULL, NULL, > - g_cclosure_marshal_VOID__POINTER, > + gpa_marshal_VOID__POINTER_POINTER, > G_TYPE_NONE, 2, > G_TYPE_POINTER, > G_TYPE_POINTER); From wk at gnupg.org Mon Aug 11 16:16:41 2025 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Aug 2025 16:16:41 +0200 Subject: [gpa PATCH] Fix incorrect callback arguments In-Reply-To: <1bce45d716ba687e794421db6ff061673d204e9d.1754793371.git.sam@gentoo.org> (Sam James via Gnupg-devel's message of "Sun, 10 Aug 2025 03:36:11 +0100") References: <1bce45d716ba687e794421db6ff061673d204e9d.1754793371.git.sam@gentoo.org> Message-ID: <87o6smosdy.fsf@jacob.g10code.de> Hi! On Sun, 10 Aug 2025 03:36, Sam James said: > Fix that by adding to gpa_marshal.list to create custom marshal types > and use those instead, and fix the argument count. I just applied your your patch. Thanks. > Note that I've sent a DCO before in August 2022 but I don't spot it in > the archives at a glance, so sent it again just now. Found that mail but I have seen no DCO attachment or separate mail. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From wk at gnupg.org Tue Aug 12 10:08:04 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Aug 2025 10:08:04 +0200 Subject: [Announce] GnuPG 2.4.8 was released in May Message-ID: <87v7mtnesb.fsf@jacob.g10code.de> Hello! We forgot to send out the announcement for GnuPG 2.4.8 which was released in May 2025. Please note that the 2.4 series will reach end-of-life on 2026-06-30 and for new systems we suggest to already use the 2.5 version. Note also the new Debian syle packages. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP (aka LibrePGP) and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.4.8 (2025-05-14) ------------------------------------------------ * gpg: Fix a verification DoS due to a malicious subkey in the keyring. [T7527] * gpg: Fix a regression in 2.4.7 for generating a key from card. [T7457] * gpg: Fix --quick-add-key for Weierstrass ECC with usage given. [T7506] * gpg: Fully implement the group key flag. [rGedd01d8fc4] * gpg: Make combination of show-only-fpr-mbox and show-unusable-uid work. [rGeb2a90d343] * gpgsm: Do not return an error code when importing a certificate with an empty subject. [T7171] * scd: Accept P15 cards with a zero-length label. [rG18b4ebb28a] * keyboxd: Use case-insensitive search for mail addresses. [T7576] * gpgconf: Fix reload and kill of keyboxd. [T7569] * w32: Fix posssible lockup due to lost select results. [rG9448d01d61] Release-info: https://dev.gnupg.org/T7428 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.8.tar.bz2 (8M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.8.tar.bz2.sig A source code version with all GnuPG related libraries: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.4.8_20250514.tar.xz (16M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.4.8_20250514.tar.xz.sig For some Debian based systems we also provide binaries. See https://repos.gnupg.org/deb/gnupg/bookworm/ https://repos.gnupg.org/deb/gnupg/trixie/ https://repos.gnupg.org/deb/gnupg/daedalus/ https://repos.gnupg.org/deb/gnupg/excalibur/ https://repos.gnupg.org/deb/gnupg/jammy/ https://repos.gnupg.org/deb/gnupg/noble/ https://repos.gnupg.org/deb/gnupg/plucky/ For the suggested 2.5 version just replace "gnupg" in the URLs by "gnupg-devel". Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.4.8.tar.bz2 you would use this command: gpg --verify gnupg-2.4.8.tar.bz2.sig gnupg-2.4.8.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.4.8.tar.bz2, you run the command like this: sha1sum gnupg-2.4.8.tar.bz2 and check that the output matches the next line: c704085aa7cc131a67edd0b7c0c90e5c35ee4adb gnupg-2.4.8.tar.bz2 c5b3e12f2cfb8771d4f6e089039d84844f6cba70 gnupg-w32-2.4.8_20250514.exe ec77cc97ff3cbe920f534b73624a608c0b10d6e6 gnupg-w32-2.4.8_20250514.tar.xz Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Turkish, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T7428 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped us in the past with their donations. *Thank you all* Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. * List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: ed25519 2020-08-24 [SC] [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [SC] [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) rsa3072 2025-05-09 [SC] [expires: 2033-03-03] 3B76 1AE4 E63B F351 9CE7 D63B ECB6 64CB E133 2EEF Alexander Kulbartsch (GnuPG Release Key) brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. * Debian Package Signing Key: The new Debian style packages are signed using this key: ed25519 2025-07-08 [SC] [expires: 2035-07-14] 3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355 GnuPG.org Package Signing Key See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the key. -- Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From collin.funk1 at gmail.com Wed Aug 13 01:04:36 2025 From: collin.funk1 at gmail.com (Collin Funk) Date: Tue, 12 Aug 2025 16:04:36 -0700 Subject: [PATCH gnupg] Fix typos in messages. In-Reply-To: <2e3bb911f4afcd9f64043a1c9a189bfc4fc31210.1754453772.git.collin.funk1@gmail.com> References: <2e3bb911f4afcd9f64043a1c9a189bfc4fc31210.1754453772.git.collin.funk1@gmail.com> Message-ID: <87bjokm9a3.fsf@gmail.com> Collin Funk writes: > * agent/gpg-agent.c (map_supervised_sockets): Fix spelling of > --deprecated-supervised. > * g10/gpg.c (main): Fix spelling of --quick-set-expire. > * scd/command.c (hlp_checkpin): Fix spelling of modifying. > * g10/decrypt.c (decrypt_message): Fix spelling of mutually. > > -- > > Signed-off-by: Collin Funk > --- > agent/gpg-agent.c | 2 +- > g10/decrypt.c | 2 +- > g10/gpg.c | 2 +- > scd/command.c | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) Hey Werner, could you check this simple change when you have chance? Thanks, Collin From wk at gnupg.org Wed Aug 13 08:09:53 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Aug 2025 08:09:53 +0200 Subject: [PATCH gnupg] Fix typos in messages. In-Reply-To: <87bjokm9a3.fsf@gmail.com> (Collin Funk's message of "Tue, 12 Aug 2025 16:04:36 -0700") References: <2e3bb911f4afcd9f64043a1c9a189bfc4fc31210.1754453772.git.collin.funk1@gmail.com> <87bjokm9a3.fsf@gmail.com> Message-ID: <87v7mrn45q.fsf@jacob.g10code.de> Hi Collin, > Hey Werner, could you check this simple change when you have chance? Just pushed. Sorry for the delay. BTW, I don't think that ChangeLog entries for typos are really needed. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: