Re: cv25519 key support on devotee
On Thu, Sep 29, 2022 at 2:50 AM Kurt Roeckx wrote: > > On Wed, Sep 28, 2022 at 07:22:38AM +0200, Kurt Roeckx wrote: > > > > As far as I understand of what is going wrong is that gnupg tries to > > write to the status fd, but libgnupg-interface-perl is trying to read > > gnupg's stdout and they just deadlock. > > So I applied this patch and things seem to work now: And I can confirm I 've received the ack now. Thanks! -- Shengjing Zhu
Re: cv25519 key support on devotee
On Wed, Sep 28, 2022 at 04:47:02PM +0200, Kurt Roeckx wrote: > On Wed, Sep 28, 2022 at 04:27:56PM +0800, Shengjing Zhu wrote: > > On Wed, Sep 28, 2022 at 07:22:38AM +0200, Kurt Roeckx wrote: > > > On Mon, Sep 26, 2022 at 12:51:48AM +0800, Shengjing Zhu wrote: > > > > Hi, > > > > > > > > Is there any plan to support cv25519 key on devotee? > > > > > > > > Or could devotee send unencrypted ack to the voter? I really don't > > > > mind the vote secrecy... But I want to see my vote hash. I see dvt-ack > > > > has something like Encrypted_Ack option, but I'm not sure if it can be > > > > run manually to send individual ack (I'm not good at reading perl > > > > scripts). > > > > > > > > Please CC me as I don't subscribe -vote. > > > > > > I've been unable to get encrypting using libgnupg-interface-perl to > > > work with gnupg 2. In bullseye it at least claims the support both > > > 1.4 and 2.2, but I can't get it to work with either. So I'm > > > currently stuck with the libgnupg-interface-perl version from buster > > > and gnupg 1.4. > > > > > > As far as I understand of what is going wrong is that gnupg tries to > > > write to the status fd, but libgnupg-interface-perl is trying to read > > > gnupg's stdout and they just deadlock. > > > > > > > After a quick checking the changelog of libgnupg-interface-perl, > > I think it is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016125 > > > > It has been fixed in bullseye-backports(1.02-2~bpo11+1). > > Could you try with that? > > That doesn't fix anything. > I did some hack on dvt-ack in a sid chroot, now I get something working. 1. As you said, there's some deadlock in the status fd. But I find the status value is not used anywhere except for logging. So just removing `status => $status_fh` in `GnuPG::Handles->new`. And anything about status_fh. 2. The `--secret-keyring` option is obsolete in gnupg2. So I hacked it by removing it, and point homedir to the real home, which should have private-keys-v1.d directory. And remove `--no-default-keyring` option. Now dvt-ack can encrypt and sign with gnupg2. Hope this can help someone to come up with a clean patch.
Re: cv25519 key support on devotee
On Wed, Sep 28, 2022 at 07:22:38AM +0200, Kurt Roeckx wrote: > On Mon, Sep 26, 2022 at 12:51:48AM +0800, Shengjing Zhu wrote: > > Hi, > > > > Is there any plan to support cv25519 key on devotee? > > > > Or could devotee send unencrypted ack to the voter? I really don't > > mind the vote secrecy... But I want to see my vote hash. I see dvt-ack > > has something like Encrypted_Ack option, but I'm not sure if it can be > > run manually to send individual ack (I'm not good at reading perl > > scripts). > > > > Please CC me as I don't subscribe -vote. > > I've been unable to get encrypting using libgnupg-interface-perl to > work with gnupg 2. In bullseye it at least claims the support both > 1.4 and 2.2, but I can't get it to work with either. So I'm > currently stuck with the libgnupg-interface-perl version from buster > and gnupg 1.4. > > As far as I understand of what is going wrong is that gnupg tries to > write to the status fd, but libgnupg-interface-perl is trying to read > gnupg's stdout and they just deadlock. > After a quick checking the changelog of libgnupg-interface-perl, I think it is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016125 It has been fixed in bullseye-backports(1.02-2~bpo11+1). Could you try with that?
cv25519 key support on devotee
Hi, Is there any plan to support cv25519 key on devotee? Or could devotee send unencrypted ack to the voter? I really don't mind the vote secrecy... But I want to see my vote hash. I see dvt-ack has something like Encrypted_Ack option, but I'm not sure if it can be run manually to send individual ack (I'm not good at reading perl scripts). Please CC me as I don't subscribe -vote. -- Shengjing Zhu
Re: Changing how we handle non-free firmware
On Mon, Aug 29, 2022 at 09:06:38AM +0200, Simon Josefsson wrote: > == > > We continue to stand by the spirit of the Debian Social Contract §1 > which says: > >Debian will remain 100% free > >We provide the guidelines that we use to determine if a work is >"free" in the document entitled "The Debian Free Software >Guidelines". We promise that the Debian system and all its components >will be free according to these guidelines. We will support people >who create or use both free and non-free works on Debian. We will >never make the system require the use of a non-free component. > > Therefore we will not include any non-free software in Debian, nor in the > main archive or installer/live/cloud or other official images, and will > not enable anything from non-free or contrib by default. > > We also continue to stand by the spirit of the Debian Social Contract §5 > which says: > >Works that do not meet our free software standards > >We acknowledge that some of our users require the use of works that >do not conform to the Debian Free Software Guidelines. We have >created "contrib" and "non-free" areas in our archive for these >works. The packages in these areas are not part of the Debian system, >although they have been configured for use with Debian. We encourage >CD manufacturers to read the licenses of the packages in these areas >and determine if they can distribute the packages on their CDs. Thus, >although non-free works are not a part of Debian, we support their >use and provide infrastructure for non-free packages (such as our bug >tracking system and mailing lists). > > Thereby re-inforcing the interpretation that any installer or image with > non-free software on it is not part of the Debian system, but that we > support their use and welcome others to distribute such work. > > == Second. signature.asc Description: PGP signature
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Mar 26, 2021 at 02:36:40PM +0100, Timo Weingärtner wrote: > Hi, > > Updated text: > ---8<---8<---8<--- > The Debian Project will not issue a public statement on whether Richard > Stallman should be removed from leadership positions or not. > > Any individual (including Debian members) wishing to (co-)sign any of the > open > letters in question is invited to do this in person. > ---8<---8<---8<--- > > This includes the change by Mathias Behrle but changes "the letter" to "any > of > the letters". > > > Grüße > Timo Seconded -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQTiXc95jUQrjt9HgU3EhUo4GOCwFgUCYF43awAKCRDEhUo4GOCw FpuXAP9ucJ2IWo67t3ks3dvNCBL1UoZN387oAm6xhZDPqDeorQD/VayZ3JvDQLqe POFsC+BKfH8VvV330cYmXX/WuAGysAE= =YUrm -END PGP SIGNATURE-
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQTiXc95jUQrjt9HgU3EhUo4GOCwFgUCYF41TwAKCRDEhUo4GOCw Fv6XAQCvPI/18AtNrtVuZDqwmjXa5WerDiNb+vJYKLomka/08gEArPCBnilXiqT3 SvfVHwvNBb44unghXKjY9ODYpAUJxwc= =9ZQo -END PGP SIGNATURE-
