Hello there,
I have read a little on this discussion and feel like sharing my thoughts.
I think the current lacking procedures are number 3 and 4 from my
summarization
based on the current standards adopted for PKI:
1) Chain of trust from developer, [intermediaries,] to root CA.
2) Ensure multiple
> $ grep mariadb results/*
> results/results_dumped.txt:libmariadb-dev
> results/results_failed.txt:libmariadbd-dev
> results/results_none.txt:libmariadb-dev
> $
>
> There was nothing unintentional here. libmariadb-dev is clean wrt time_t.
> libmariadbd-dev failed to be analyzed because it has hea
On Sun, Feb 04, 2024 at 04:08:43PM -0800, Otto Kekäläinen wrote:
> +1 for MariaDB for the above. Also I think the package name change was
> done for the wrong package, it should probably have been done for
> libmariadb3 and not for libmariabd19.
> apt-cache rdepends --no-recommends --no-suggests l
Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar
X-Debbugs-Cc: debian-devel@lists.debian.org, kd8...@gmail.com
* Package name: python-respx
Version : 0.20.2
Upstream Contact: Jonas Lundberg
* URL : https://github.com/lundberg/respx
* License : BSD
Package: wnpp
Severity: whishlist
Owner: Patrick Winnertz
X-Debbugs-Cc: debian-devel@lists.debian.org
Package name: qttinysa
Version : 0.9.1
Upstream Author : Ian (g4ixt)
URL : https://github.com/g4ixt/QtTinySA
License : GPL-v3
Programming Lang: Python
Descrip
On 2024-02-05 08:58, Simon Josefsson wrote:
What would be involved is to 1) during signing of artifacts, also sign
and upload into Sigstore/Sigsum, and 2) during verification in the
f-droid app, also verify that the signature has been committed to the
Sigstore/Sigsum logs. Both projects have cli
Your work is valuable. Many of the things have probably evolved over
time and could use some analysis based on modern cryptography and
security practices. I just wanted to point out that there are subtle
but important differences outside of the key and signature formats.
The most important distinc
Stephan Verbücheln writes:
> II. Typical Debian case
>
> 1. Debian developer signs source tarballs and upload them
> 2. The signature only has to be secure until the code lands in the FTP
> 3. Debian builds the binary packages
> 4. Debian creates Release files with hashes of the packages
> 5. The
Code signing is not equal to code signing. There are a lot of
differences between different code-signing strategies, many of which
are often overlooked.
Example:
I. Typical Windows case
1. Third-party developer gets a key from a CA.
2. Third-party developer signs a program binary.
3. The user ob
On Sat, Jan 26, 2013 at 12:38:07AM +, Stuart Prescott wrote:
> Package: wnpp
> Severity: normal
>
> The maintainer for the "nvi" package has indicated that he is unable to
> maintain this package for the time being. I'm marking this package as orphaned
> now. If you want to be the new maintain
Bill Allombert writes:
> On Mon, Feb 05, 2024 at 08:49:09AM +0100, Simon Josefsson wrote:
>> Bill Allombert writes:
>>
>> > Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit :
>> >> Hi
>> >>
>> >> I'm exploring how to defend against an attacker who can create valid
>> >> signat
On Mon, Feb 05, 2024 at 08:49:09AM +0100, Simon Josefsson wrote:
> Bill Allombert writes:
>
> > Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit :
> >> Hi
> >>
> >> I'm exploring how to defend against an attacker who can create valid
> >> signatures for cryptographic private key
Hi,
On 2024-02-05 09:05, Steve Langasek wrote:
On Mon, Feb 05, 2024 at 08:57:50AM +0200, Andrius Merkys wrote:
Given libfoo1 in unstable and libfoo2 in experimental, I assume libfoo1t64
will be NMU'd directly to unstable. After that happens, will it be OK to
upload libfoo2 to unstable (as part
13 matches
Mail list logo
