Re: RFS: dnstwist
Hi Peter, Peter Wienemann 於 2020年3月27日 週五 上午2:12寫道： > > Hi SZ, > > On 25.03.20 04:39, SZ Lin (林上智) wrote: > > Thanks for your contribution, I've created this repository and import your > > commits in the pkg-security team. > > > > [1] https://salsa.debian.org/pkg-security-team/dnstwist > > [...] > > > I didn't see any issues, but one thing to be aware of that someone > > also wrote a manpage of dnstwist and sent the PR to the upstream. > > > > [2] https://github.com/elceef/dnstwist/pull/91/files > > thank you for your review, the repository creation and the upload. > > Concerning the manpage, I will discard the present one as soon as the > mentioned PR has been merged. Thanks. > > Do I have permission to push updates to the newly created repository? Regarding the commit right, please refer to the below link [1], you can send the MR even though you don't have the commit right in dnstwist. [1] https://wiki.debian.org/Teams/pkg-security#Get_commit_rights SZ > > Peter >
[SECURITY] [DSA 4647-1] bluez security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian Security Advisory DSA-4647-1 secur...@debian.org https://www.debian.org/security/ Salvatore Bonaccorso March 26, 2020https://www.debian.org/security/faq - - Package: bluez CVE ID : CVE-2020-0556 Debian Bug : 953770 It was reported that the BlueZ's HID and HOGP profile implementations don't specifically require bonding between the device and the host. Malicious devices can take advantage of this flaw to connect to a target host and impersonate an existing HID device without security or to cause an SDP or GATT service discovery to take place which would allow HID reports to be injected to the input subsystem from a non-bonded source. For the HID profile an new configuration option (ClassicBondedOnly) is introduced to make sure that input connections only come from bonded device connections. The options defaults to 'false' to maximize device compatibility. For the oldstable distribution (stretch), this problem has been fixed in version 5.43-2+deb9u2. For the stable distribution (buster), this problem has been fixed in version 5.50-1.2~deb10u1. We recommend that you upgrade your bluez packages. For the detailed security status of bluez please refer to its security tracker page at: https://security-tracker.debian.org/tracker/bluez Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/ Mailing list: debian-security-announce@lists.debian.org -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEERkRAmAjBceBVMd3uBUy48xNDz0QFAl59Lf9fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2 NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQACgkQBUy48xND z0QYMA/+JBxFU7rzhzE+cQMnw0zhQ7v5eJg6Xmqxc7oCOgrbjCSfOS7f6FkieJxs crx6lG8g8TJAT3p+3UB/V7K7qZ7eR4WyebuFO9Zhzw++/Lta/WHYG/HJeLaLziBC G9PewvpioBZep60t/GtS9hJ322XFMVmi05rq9jfEVmAtkGXQ2YFcZm6EIevI/C4j EwmAFMszh2jCozevWo5//pgy5aVNKWoWZNjK836sIb8m3xkmRLkM55vwU05qGYFp p5tz9Weqt6gFbSzRkVfuiqz2duYltdquw38O3kgpqci5stKNw3z2SQMnhj4n1JcB yM9gdlK651eGEvZ9j402dbXtyr18cQ0svsZDwoKQ1B61nsZtyS026Ecj/c4HluBF LbBH/kE/oQW7kU2yfDcWdKH8ISZSL0d/JpfUl0qXvpNx33ApjSiNMsOzf0/b8SKc WsYpsdS5WYq8wgG8Orhaa51cw8zoCNZRdx58njYyxWGMszDa9LbZk+Hgr4fad96y wUo3rGNxz6EC26ewUtSPToXXnGmRLhp1rg40zvNMNE42KenlkR5kipn203OSxuw4 g+CHJ2whA5YM9Dr6z1NF1udDGAqdq+TeI/uY4WY/JT6NbawZ+ziFGcKetATYiwIL wAdYopw3DleEPGSEifbavriVqWBv0biTy9oVR/YeltiEE9UjNpY= =odxF -END PGP SIGNATURE-
I'm a DM now, was: Re: arno-iptables-firewall 2.0.3-3 ready for review and upload
Hello Samuel, Hello Team, just wanted to let you know I successfully finalized the process to become a DM. My key has been added to the active DM keyring according to a notification I received on Tuesday. Samuel, please enable upload rights for arno-iptables-firewall for me. I'd like to thank all of you who supported me to attain the necessary expertise to become a DM. Regards, Sven Am Montag, den 02.12.2019, 22:01 + schrieb Samuel Henrique: > Hello Sven, > > > > Your suggestion is an honor to me. I just studied what's on nm.d.o > > and > > intend to apply soon. > > > > It's all result of your hard work :) > > > PS.: If you've been contributing to the team for some time and > > > you feel like you're ready to become a DM/DD, feel free to ping > > > whoever worked more with you to discuss about it, sometimes > > > we just overlook things and forget to ask people to apply. > > I forgot to make it more clear, this PS. part is for the rest of the > team. > > I will advocate for you (Sven) as soon as you apply, just ping me. > For DM only one advocate is required, more is better, sometimes other > people from the team might do it when they see your application, or > you > might ask them directly, but you already have the required number of > advocates so you can start the process as soon as you want, it's your > call now to wait or not :) > > Regards, > signature.asc Description: This is a digitally signed message part
Re: RFS: dnstwist
Hi SZ, On 25.03.20 04:39, SZ Lin (林上智) wrote: > Thanks for your contribution, I've created this repository and import your > commits in the pkg-security team. > > [1] https://salsa.debian.org/pkg-security-team/dnstwist [...] > I didn't see any issues, but one thing to be aware of that someone > also wrote a manpage of dnstwist and sent the PR to the upstream. > > [2] https://github.com/elceef/dnstwist/pull/91/files thank you for your review, the repository creation and the upload. Concerning the manpage, I will discard the present one as soon as the mentioned PR has been merged. Do I have permission to push updates to the newly created repository? Peter
Re: debcheckroot v2.0 released
Am 26.03.20 um 03:50 schrieb Paul Wise: On Wed, 2020-03-25 at 11:27 +0100, Elmar Stellnberger wrote: OpenPGP is no solution to the issue. DANE is not gonna disappear. I guess we will have to agree to disagree, end of thread for me. I am far from not having to say more about it. Most people who provide signatures store their private key on a machine also used for web browsing. I know this also applies to Debian because keeping the key secure or at best offline would require some considerable provisions and AFAIK none of you have implemented a separation of concerns i.e. one computer for browsing and another one for secure ssh connections. That would be required though to keep the secret key safe. We have an arbitrary code execution bug in browsers every few month and that does not count all the zero day exploits at all. Sites in the www are commonly spoofed by secret services. Even the Snowden revelations do tell (operation Quantum insert). That way the secret key is guaranteed to be compromised a few milliseconds after its creation. The NSA also has its own key stealing programme. I wanna tell you that you are better off checking the SHA512SUM. That one, as soon as you have retrieved a genuine one, can no more be spoofed. Besides this it is a common attack vector to infect computers via online updates. Once more they need to know the secret key in order to do so!
External check
CVE-2019-11939: TODO: check CVE-2020-10688: RESERVED CVE-2020-10689: RESERVED CVE-2020-1762: RESERVED CVE-2020-1764: RESERVED CVE-2020-7407: RESERVED CVE-2020-8832: RESERVED -- The output might be a bit terse, but the above ids are known elsewhere, check the references in the tracker. The second part indicates the status of that id in the tracker at the moment the script was run.
