Reply-To: Marcus Dean Adams
To: Elmar Stellnberger , Rebecca N. Palmer
, debian-security@lists.debian.org
It's better than nothing. Even if somebody were using self signed
certificates that aren't publicly trusted, the information would still
be encrypted in transit. Whethe
Davide Prina wrote:
Not all the software that implement HTTPS verify the validity of the
certificate and the validity of all the certification chain.
These scripts are using wget or curl, which both say they do verify
certificates. If they do not do so correctly, please report this.
For exam
On 01/05/2020 20:31, Elmar Stellnberger wrote:
https isn´t any more secure than http as long as you do not have a
verifiably trustworthy server certificate that you can check for. As we
know the certification authority system is totally broken.
Imperfect yes, but still better than nothing.
It
Around 200 packages [0] include upstream scripts that download code via
(non-secure) http, then run it without an integrity check.
This is obviously a security hole (network MITM => code execution), but
not necessarily one that is opened by normal use of the package. (E.g.
fetch-dependencies-
On 15/08/2019 21:57, Rebecca N. Palmer wrote:
Paul Wise wrote:
Based on the serial number deletion, I'd speculate that some internal
part of the flash holding details about the device identity
malfunctioned, so the firmware reverted back to the default hardcoded
product id for Alcor
On 17/08/2019 12:18, Elmar Stellnberger wrote:
to be safe the key
handling policy needs to be offline enforced
There have been various attempts to encourage / simplify the use of
offline keys, but it isn't currently required in Debian, and some of
them only suggest keeping the master key (not
I have now done the check from a boot DVD: clean, but as already noted,
there are places it doesn't check.
On 16/08/2019 20:14, Elmar Stellnberger wrote:
Concerning your program I
have seen that it uses /var/lib/dpkg/info/$2.md5sums. This is inherently
unsafe because an attacker can simply alt
Paul Wise wrote:
but at least some USB flash drives instead use an SCSI command [1],
which usbguard won't catch.
This seems like a significant missing feature, but I guess it would
require a fair bit of Linux kernel work to support filtering such
commands.
If the attacker has root (which they
(Warning: this is being sent from the affected computer, so don't trust
"me". BCCd recipients: anyone can post to the debian-security list, but
be aware that its public archive does not spam-protect email addresses)
I use usbguard [0], set to allow only the specific USB devices I have.
One of
(continued from
https://lists.debian.org/debian-security/2017/11/msg9.html )
I seem to be banned from contacting Daniel Pocock by his spam filter, so
I decided to write my own scripts, which turned into a rather bigger
project than I'd planned on.
Note that while this takes no code from
Background: my sponsor suggested that I apply for DM over a year ago,
and the reason I haven't done so is that I'm not sure my security is up
to it, given that anyone who hacks a DM can upload a Trojan. I only own
one computer [0] (meaning it gets used for everything from contributing
to casua
What is the legal problem here? I think the default license for the .spec file
is MIT:
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#License_of_Fedora_SPEC_Files
None now I'm aware of that policy - I just hadn't found it before.
Control: merge -1 813809
I'd also like to see this (or an equivalent: I'm not aware of any, but
haven't looked much) in Debian, and am willing to try packaging it, but
am not sure whether it's a good idea for a non-DD,
non-security-specialist to maintain a security tool.
It's in Fedora, with
13 matches
Mail list logo
