Re: testssl.sh 3.0~rc5+dfsg1 in Debian
Howdy, First off, thanks for your response! On Tue, 5 Nov 2019, Samuel Henrique wrote: Hello Unit, After looking into testssl.sh again, I noticed on the release page[0] it states that 2.9.5 won't be supported once 3.0 lands, and encourages distributors to pick up 3.0rc5. I did some packaging work[1] to import the new version, refresh patches, and other minor things and it'd be cool if you could pull the changes. This version is specifically interesting as it has support for TLS 1.3. I really appreciate your work, but version 3.0 of testssl has a licensing issue that needs to be resolved before packaging it for Debian: upstream decided to add a clause to their GPL license stating that any public use of it must mention where they've got the program from. I'm worried as to how this relates to the DFSG, more specifically: https://github.com/drwetter/testssl.sh/blob/3b89dc6b0a41299fbf462789998e4c103f4f0210/testssl.sh#L19-L22 Correct me if I'm wrong, but from what I'm reading, the section you point to is already in Debian[0], and was actually there since the initial upload[1]? There was a minor wording change in 5257c2f3 but as I understand it one was already bound to the license anyway. I *think* this is ok (didn't thought enough about it) but I feel like a discussion on debian-legal would be better and I don't feel confident uploading this without it. Did you notice that as well? What are you thoughts on it? I'd think since the initial upload passed review, the wording change wouldn't be any cause for alarm since that's just about having to obey the license. But I would happily read any other opinions! On a sidenote, if I remember correctly, testsssl suffers from the same issue as o-saft, another ssl vuln detector, as it needs to have an old version of openssl to check for legacy stuff, otherwise it won't support them. Yeah, the tarballs bundle openssl with all options enabled, part of the repacking removes that. It loses the ability to detect some issues but still can be quite useful! I recently used this to check one of my other packages while testing a patch for WolfSSL support. It showed a hang with TLS 1.3 whereas everything else worked. [0]: https://sources.debian.org/src/testssl.sh/2.9.5-7+dfsg1-2/testssl.sh/#L22 [1]: https://salsa.debian.org/pkg-security-team/testssl.sh/blob/4b771208e63d86a094743b7b0c3994ef9f141646/testssl.sh#L21 ~Unit 193 Unit193 @ OFTC Unit193 @ freenode
tomb (2.7+dfsg2-1) ready for review and upload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Eriberto, Hello Team, I believe I've sorted out all the copyright issues. As a result Tomb 2.7+dfsg1-1 became 2.7+dfsg2-1, I had to drop another doc file from the original upstream tarball. Please review und upload [1]. Thanks, Sven [1] https://salsa.debian.org/pkg-security-team/tomb Am Montag, den 04.11.2019, 20:21 -0300 schrieb Eriberto: > Sorry but I forgot a detail... > > Please, update the block debian/* in debian/copyright file. You need > include Andreas and Raphael names and update some dates. Use: egrep > '(@|\[)' debian/changelog > > Cheers, > > Eriberto > -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEPfXoqkP8n9/QhvGVrfUO2vit1YUFAl3CBEkACgkQrfUO2vit 1YXFxxAAusg4pcMmjLP2yB8rA3gtDEUQ0QMZ2bgSVCV7/xLTYQP/DoxBIpmkmDEm HvEhdadquzxN2Ms9bzzahY7bB2iM794Am4ZEtIXcIRp8s2BypPZlSb0+Bwn9gNCy cSSf8BSRgDZSJOoC3pupqUqx/4FVpvYT/JsfiYTMhfrEQmo/yr8d13JpP2WOmrmJ MRsHePPb8GLVbDBui+qw9JXHkaXyjQGaGXgiY48Zl9EMVLXvpDjFuwsIf3l53u/7 TTkLH8eBH+/MdTqioUBmDWbzxbraoIY5LbGPzRry8X0jC6zTTUL9kbQGvSKsWTgD oGOi/zDRIrftS5z4ISJdWNPxMNKIyWXFAuv94mJMdtaVFV3iXhavKgn9kfLXPRZD 3T11l6VLDUx6UdXMMDki/nFLI7zy4TeYWuiie6BP5Cg3tIx8W+7qtPM20RK9lLLw O9KW4BZKKl02c2u1K9/bfRUR/qytHhngPFMVkbW0hAmkuyP3/uAiOfk7hv8JuzYD 3ID0CR2nLmg+JHsZIc84/8f3kWU7SYqYMpLp0dpl4HPkztK8PsESearPaOIDhLcQ rbbnXn+aeH/0T3YOjUq5eaM54/6/ov2+3cGJxOOytMwD0GQqgbzwKDzy3Jh4CFEa 5U0JX7fMVYVv2QkC63ol4Hg5ma9rMFADYHo3LqFubtD9F6cLU7k= =R1gX -END PGP SIGNATURE-
Re: [request-for-help] o-saft maintenance and openssl
S... What I would like to do here is to ask upstream to bundle/vendor the old version of openssl o-saft need, and build it and install inside the o-saft folder and statically linking to it. I would say to try to bundle as minimal things as possible from the old openssl release but I didn't investigate it to know how much realistic this stripping down is. I imagine it could also be possible to try to make it as hard as possible to link against it, but again I didn't investigate so I don't know how realistic this is. Considering upstream is willing to help, this would be good things to ask for, I just don't wanna ask for a bunch of stuff, having upstream spending time implementing it, so then I get blocked later because I asked for something that is unacceptable bu the ftp-master team. So I would like if some other team members could give me some insights on this, if they think this is feasible, or even if they don't have any idea about it. Regards, -- Samuel Henrique
Re: Bug#944129: arp-scan: not returning any results
Hello
I just uploaded a new release of arp-scan to git [0]. I tested it and
it works well on my machine (Debian testing).
Could some DD review and upload the package?
Greetings,
Marcos
[0] https://salsa.debian.org/pkg-security-team/arp-scan
El lun, 04-11-2019 a las 18:42 +0100, Reiner Herrmann escribió:
> Package: arp-scan
> Version: 1.9.5-1
> Severity: serious
> Tags: fixed-upstream
>
> Dear maintainer,
>
> arp-scan is no longer returning any results in Debian sid.
>
> > # arp-scan 10.0.0.0/24
> > Interface: wlan0, datalink type: EN10MB (Ethernet)
> > Starting arp-scan 1.9.5 with 256 hosts (
> > https://github.com/royhills/arp-scan)
> >
> > 14 packets received by filter, 0 packets dropped by kernel
> > Ending arp-scan 1.9.5: 256 hosts scanned in 2.031 seconds (126.05
> > hosts/sec). 0 responded
>
> With wireshark I can actually see arp replies (and it sounds like
> they
> were also received ("14 packets received")),
> With another machine that is running buster I can still see the
> results, so it could have been introduced by a different libpcap
> version?
>
> After noticing that the bug has also been filed in Ubuntu [0],
> I also tested the version from git and got it running successfully.
> This is the first commit at which it is returning results again: [1].
> It is contained in the new upstream release 1.9.6.
>
> Kind regards,
> Reiner
>
> [0] https://bugs.launchpad.net/ubuntu/+source/arp-scan/+bug/1849740
> [1] https://github.com/royhills/arp-scan/commit/8513a18
Re: testssl.sh 3.0~rc5+dfsg1 in Debian
Hello Unit, After looking into testssl.sh again, I noticed on the release page[0] it > states > that 2.9.5 won't be supported once 3.0 lands, and encourages distributors > to > pick up 3.0rc5. I did some packaging work[1] to import the new version, > refresh > patches, and other minor things and it'd be cool if you could pull the > changes. > > This version is specifically interesting as it has support for TLS 1.3. > I really appreciate your work, but version 3.0 of testssl has a licensing issue that needs to be resolved before packaging it for Debian: upstream decided to add a clause to their GPL license stating that any public use of it must mention where they've got the program from. I'm worried as to how this relates to the DFSG, more specifically: https://github.com/drwetter/testssl.sh/blob/3b89dc6b0a41299fbf462789998e4c103f4f0210/testssl.sh#L19-L22 I *think* this is ok (didn't thought enough about it) but I feel like a discussion on debian-legal would be better and I don't feel confident uploading this without it. Did you notice that as well? What are you thoughts on it? On a sidenote, if I remember correctly, testsssl suffers from the same issue as o-saft, another ssl vuln detector, as it needs to have an old version of openssl to check for legacy stuff, otherwise it won't support them. Regards, -- Samuel Henrique
