Re: Ditching OpenPGP, a new approach to signing APT repositories

[Bernhard Reiter]

Am Sonntag 27 Juni 2021 18:56:15 schrieb Стефан Васильев via Gnupg-users:
> maybe interesting for some of you.
> https://wiki.debian.org/Teams/Apt/Spec/AptSign

This does not have references on the problems it is claiming to address.

No description of the context where it is supposed to be used
and what part it will play in the security.

Also there is no mention of how the trust relation of the public
keys will be established.

So not yet possible to evaluate the page, it looke like a 0.2 draft
in a wiki and probably gets to the point of being an interesting proposal 
later.

Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: recommendation for key servers

[C.J. Collier]

*keyserver of course.

Please excuse my html, typos and use of soft keyboards.

On Mon, Jun 28, 2021, 16:33 C.J. Collier  wrote:

> I was thinking of build a keystone out of perl and bigquery, but I haven't
> gotten around to it yet.  At least not the bigquery part.  I'll share the
> perl http listener and dispatch server if anyone's interested.
>
> On Sun, Jun 27, 2021, 18:04 Jason Harris via Gnupg-users <
> gnupg-users@gnupg.org> wrote:
>
>>
>> There are still SKS servers running, but several are unsynchronized,
>> including, apparently, pgp.mit.edu.  Of course, they have the same key
>> import/poisoning problems already mentioned on these lists…
>>
>> Here are the hockeypuck servers I could find, all synchronizing properly
>> and apparently exchanging data (minus the unwanted packets) with the SKS
>> servers that are synchronized:
>>
>>- http://keys.andreas-puls.de/pks/lookup?op=stats
>>- http://keys2.andreas-puls.de/pks/lookup?op=stats
>>- http://keys3.andreas-puls.de/pks/lookup?op=stats
>>- http://pgp.cyberbits.eu/pks/lookup?op=stats
>>- http://pgp.re:11371/pks/lookup?op=stats
>>- https://pgpkeys.eu/pks/lookup?op=stats
>>- https://keybath.trifence.ch/pks/lookup?op=stats
>>- https://keyserver.trifence.ch/pks/lookup?op=stats
>>
>> HTH.  (Please excuse the HTML.)
>>
>> Sent from my iPad
>>
>> On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel <
>> gnupg-de...@gnupg.org> wrote:
>>
>> 
>> Hi, we heard that sks-keyservers.net will be depreciated
>> so we were wondering what service we should use in the application
>> default settings
>> We I mean TDE devs
>>
>> where do we go from here?
>>
>> thank you in advance
>> BR
>> ___
>> Gnupg-devel mailing list
>> gnupg-de...@gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>>
>> ___
>> Gnupg-users mailing list
>> Gnupg-users@gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: recommendation for key servers

[C.J. Collier]

I was thinking of build a keystone out of perl and bigquery, but I haven't
gotten around to it yet.  At least not the bigquery part.  I'll share the
perl http listener and dispatch server if anyone's interested.

On Sun, Jun 27, 2021, 18:04 Jason Harris via Gnupg-users <
gnupg-users@gnupg.org> wrote:

>
> There are still SKS servers running, but several are unsynchronized,
> including, apparently, pgp.mit.edu.  Of course, they have the same key
> import/poisoning problems already mentioned on these lists…
>
> Here are the hockeypuck servers I could find, all synchronizing properly
> and apparently exchanging data (minus the unwanted packets) with the SKS
> servers that are synchronized:
>
>- http://keys.andreas-puls.de/pks/lookup?op=stats
>- http://keys2.andreas-puls.de/pks/lookup?op=stats
>- http://keys3.andreas-puls.de/pks/lookup?op=stats
>- http://pgp.cyberbits.eu/pks/lookup?op=stats
>- http://pgp.re:11371/pks/lookup?op=stats
>- https://pgpkeys.eu/pks/lookup?op=stats
>- https://keybath.trifence.ch/pks/lookup?op=stats
>- https://keyserver.trifence.ch/pks/lookup?op=stats
>
> HTH.  (Please excuse the HTML.)
>
> Sent from my iPad
>
> On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel <
> gnupg-de...@gnupg.org> wrote:
>
> 
> Hi, we heard that sks-keyservers.net will be depreciated
> so we were wondering what service we should use in the application default
> settings
> We I mean TDE devs
>
> where do we go from here?
>
> thank you in advance
> BR
> ___
> Gnupg-devel mailing list
> gnupg-de...@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: recommendation for key servers

[Jean-Jacques Brucker via Gnupg-users]

"Hell is paved with good intention."

GDPR came from the laudable intention of limiting the power of GAFAMs 
and other data brokers, inside our private lives.


But the text maintains a confusion between personal data and private 
data. Some personal data is not and should not be private. Email could 
be one of them, if everyone used a web of trust, which would allow us to 
know more precisely who is the sender, and to fight more effectively 
against SPAM.


(NB: In addition, the text annoys small organizations more than large 
groups which have the means to circumvent it, via internationalization 
and lobbying)


I have a public email, and i would like to have a email service or 
client which may delete automatically unsigned messages, and give me the 
feature to order received email depending from a "proximity" regarding 
the WOT, or a "confidence" regarding my trustdb.


About the keystore, I imagined 9 years ago that a key server receiving a 
certificate update, not signed by its owner, could send a message to the 
owner (by default 1 time per day), in order to ask it to validate, or 
not, the modifications, before synchronizing the updated certificate, 
signed by its owner, on other key servers.


So I had to write a draft and start implementing a new MIME type for 
HTTP for these purposes, to upgrade HKP protocol :


https://github.com/Open-UDC/open-udc/blob/master/docs/rfc/HTTP_OpenPGP_Authentication.draft.txt

https://github.com/Open-UDC/thttpgpd

But unfortunately I was perhaps too shy to talk about these ideas on an 
international mailing list, and they received little echo in my French 
environment :


https://linuxfr.org/users/jbar/journaux/thttpgpd-ou-comment-openudc-a-ressuscite-le-bon-vieux-thttpd


Today WKD / WKS seems to me a good compromise for the trilemma keystore, 
and probably the best way to get the last version of 
"first-party-attested" certificates, which fresh uid / sub-keys updates 
and revocations.


But it's only today that I discovered your git repository 
https://gitlab.com/openpgp-wg/rfc4880bis and your idea of 
​​"first-party-attested third-party certifications" (1pa3pc).


I therefore apologize if I do not add anything new or interesting to the 
debate today.



Jean-Jacques B.


Le 28/06/2021 à 01:41, Jason Harris via Gnupg-devel a écrit :


There are still SKS servers running, but several are unsynchronized, 
including, apparently, pgp.mit.edu.  Of course, they have the same key 
import/poisoning problems already mentioned on these lists…


Here are the hockeypuck servers I could find, all synchronizing 
properly and apparently exchanging data (minus the unwanted packets) 
with the SKS servers that are synchronized:


  * http://keys.andreas-puls.de/pks/lookup?op=stats
  * http://keys2.andreas-puls.de/pks/lookup?op=stats
  * http://keys3.andreas-puls.de/pks/lookup?op=stats
  * http://pgp.cyberbits.eu/pks/lookup?op=stats
  * http://pgp.re:11371/pks/lookup?op=stats
  * https://pgpkeys.eu/pks/lookup?op=stats
  * https://keybath.trifence.ch/pks/lookup?op=stats
  * https://keyserver.trifence.ch/pks/lookup?op=stats

HTH.  (Please excuse the HTML.)

Sent from my iPad

On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel 
 wrote:



Hi, we heard that sks-keyservers.net  will 
be depreciated
so we were wondering what service we should use in the application 
default settings

We I mean TDE devs

where do we go from here?

thank you in advance
BR
___
Gnupg-devel mailing list
gnupg-de...@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


___
Gnupg-devel mailing list
gnupg-de...@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


OpenPGP_0xA3983A40D1458443.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: gpgme_op_decrypt segfault

[Schultschik, Sven via Gnupg-users]

Hello all together,

I have created a small Applikation to zip and encrypte and vise versa.

I struggle at the point of  err = gpgme_op_decrypt(ctx, in, out); 
Which terminates with an segfault if not sufficient access rights are
available. If I run with sudo it works as expected.

The segfault is not catchable, I tried.

Am I doing something wrong or is this a bug in the lib? I would expect a
catchable exception.

Here is a little code snippet from the application.

int decryptBackup(string backupname, string webpw)
{
fprintf(stderr, "Decrypte backup start\n");
filesystem::path encryptedFullBackupPath;
try
{
encryptedFullBackupPath = getFullBackupPath(backupname, true);
}
catch (exception &ex)
{
if (webpw != "")
{
throw ex;
}
return false;
}

gpgme_check_version(NULL);

gpgme_ctx_t ctx;
gpgme_error_t err;
gpgme_data_t in, out;
gpgme_decrypt_result_t result;

init_gpgme();

err = gpgme_new(&ctx);
fail_if_err(err);
gpgme_set_armor(ctx, 1);
fprintf(stderr, "instream\n");
FILE *instream;
instream = fopen(encryptedFullBackupPath.c_str(), "r");
if (instream == NULL)
{
throw runtime_error("Backup archive not found " +
encryptedFullBackupPath.string() + "\n");
}
err = gpgme_data_new_from_stream(&in, instream);
fail_if_err(err, in, out, instream);
fprintf(stderr, "outstream\n");
filesystem::path fullBackupPath = getFullBackupPath(backupname, false,
false);
FILE *outstream;
outstream = fopen(fullBackupPath.c_str(), "w");
err = gpgme_data_new_from_stream(&out, outstream);
fail_if_err(err, in, out, instream, outstream);

if (!(webpw.empty() || webpw == ""))
{
_pw = webpw;

err = gpgme_set_pinentry_mode(ctx, GPGME_PINENTRY_MODE_LOOPBACK);
fail_if_err(err, in, out, instream, outstream, fullBackupPath);

gpgme_set_passphrase_cb(ctx, passphrase_cb, NULL);
}
fprintf(stderr, "gpgme_op_decrypt(ctx, in, out)\n");
try{
 err = gpgme_op_decrypt(ctx, in, out);
}catch (const char *msgc)
{
string msg = msgc;
size_t found = msg.find("Segmentation");
fprintf(stderr, "lib const char. %s\nFound %zi\n", msgc, found);
if (found != string::npos)
fprintf(stderr, "No permission.\n");
else
fprintf(stderr, "%s\n", msgc);
exit(EXIT_FAILURE);
}
catch (const std::exception &e)
{
string msg = e.what();
size_t found = msg.find("Segmentation");
fprintf(stderr, "lib exception. %s\nFound %zi\n", msg.c_str(),
found);
if (found != string::npos)
fprintf(stderr, "No permission.\n");
else
fprintf(stderr, "%s\n", msg.c_str());
exit(EXIT_FAILURE);
}
catch (...)
{
fprintf(stderr, "Unexcpected error!\n");
exit(EXIT_FAILURE);
}

fail_if_err(err, in, out, instream, outstream);

fprintf(stderr, "gpgme_op_decrypt_result(ctx)");
result = gpgme_op_decrypt_result(ctx);

if (result->unsupported_algorithm)
{
string err(result->unsupported_algorithm);
throw runtime_error("Unsupported algorithm: " + err + "\n");
}

fprintf(stderr, "Decrypte backup closing");
fclose(instream);
fclose(outstream);
gpgme_data_release(in);
gpgme_data_release(out);
gpgme_release(ctx);

fprintf(stderr, "Decrypte backup return");
return true;
}


Thank you 


Regards

Sven

-Ursprüngliche Nachricht-
Von: Gnupg-de  Im Auftrag von Bernhard Reiter
Gesendet: Montag, 14. Juni 2021 10:59
An: gnupg...@gnupg.org
Betreff: Re: gpgme_op_decrypt segfault

Hallo 

Am Freitag 11 Juni 2021 17:12:58 schrieb Schultschik, Sven:
> err = gpgme_op_decrypt(ctx, in, out); einen nicht catchbaren 
> Segmentation fault schmeißt, wenn die user rechte nicht ausreichend sind.
>
> Sollte gpgme_op_decrypt nicht den err zurückgeben, wenn etwas schief geht?

prinzipiell würde ich das auch erwarten. Es kommt aber auch darauf an, da es
ja unendlich viele spannende Problemfälle geben kann, ist bei manchen ein
komplettes Aussteigen nicht ganz verkehrt. Manchmal ist auch soviel kaputt,
dass ein sinnvolles Fehlerberichten nicht möglich ist.

Wenn Du ein leicht nachvollziehbares Beispiel hast, dann lohnt es sich
vielleicht, das auf dev.gnupg.org zu berichten.

Gruß,
Bernhard

--
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.intevat
ion.de%2F~bernhard&data=04%7C01%7Csven.schultschik%40siemens.com%7C7fe8a
2cb993f47eccb0908d92f12b183%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637
592580044549461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=M9pAUowNtoP0mEgnegAWPeF2wEYm
AEKfCU3bRgg2FCI%3D&reserved=0   +49 541 33 508 3-3 Intevation GmbH,
Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank
Koormann, Bernhard 

Re: recommendation for key servers

[Стефан Васильев via Gnupg-users]

Andrew Gallagher wrote:

On 28 Jun 2021, at 18:02, Стефан Васильев via Gnupg-users 
 wrote:


When looking at the stats, why are there IMHO such high numbers
(daily) on updated pub keys, compared to submitted ones?


It’s not clear, but it may be due to a lack of canonical ordering of
packets. Say Alice and Bob have both signed my key, but keyserver A
and keyserver B have different copies of my key with Alice and Bob’s
signatures in opposite order from each other. These keys will have
different checksums, even though they contain the same functional
information. If the sync process doesn’t result in A and B reordering
the sigs in the same way, then they will keep syncing (successfully!)
forever, incrementing the number of changes each time.


Ah, thanks. That makes sense, but could be then considered, software
wise, as unwanted behaviour.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: recommendation for key servers

[Andrew Gallagher via Gnupg-users]

> On 28 Jun 2021, at 18:02, Стефан Васильев via Gnupg-users 
>  wrote:
> 
> When looking at the stats, why are there IMHO such high numbers
> (daily) on updated pub keys, compared to submitted ones?

It’s not clear, but it may be due to a lack of canonical ordering of packets. 
Say Alice and Bob have both signed my key, but keyserver A and keyserver B have 
different copies of my key with Alice and Bob’s signatures in opposite order 
from each other. These keys will have different checksums, even though they 
contain the same functional information. If the sync process doesn’t result in 
A and B reordering the sigs in the same way, then they will keep syncing 
(successfully!) forever, incrementing the number of changes each time. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: recommendation for key servers

[Стефан Васильев via Gnupg-users]

Jason Harris wrote:


There are still SKS servers running, but several are unsynchronized,
including, apparently, pgp.mit.edu. Of course, they have the same key
import/poisoning problems already mentioned on these lists…

Here are the hockeypuck servers I could find, all synchronizing
properly and apparently exchanging data (minus the unwanted packets)
with the SKS servers that are synchronized:

* http://keys.andreas-puls.de/pks/lookup?op=stats
* http://keys2.andreas-puls.de/pks/lookup?op=stats
* http://keys3.andreas-puls.de/pks/lookup?op=stats
* http://pgp.cyberbits.eu/pks/lookup?op=stats
* http://pgp.re:11371/pks/lookup?op=stats
* https://pgpkeys.eu/pks/lookup?op=stats
* https://keybath.trifence.ch/pks/lookup?op=stats
* https://keyserver.trifence.ch/pks/lookup?op=stats


Thanks for the info.

When looking at the stats, why are there IMHO such high numbers
(daily) on updated pub keys, compared to submitted ones?

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users