Date: Fri Jun 19 15:00:32 2020 +0200
Add const to 'ppin' function parameter
CLA: trivial
Reviewed-by: Kurt Roeckx
Reviewed-by: Matt Caswell
GH: #12205
---
Summary of changes:
doc/man3
On Sun, Sep 20, 2020 at 02:36:44PM +0200, Jérémy Lal wrote:
> Le dim. 20 sept. 2020 à 12:00, Kurt Roeckx a écrit :
>
> > Package: nodejs
> > Severity: wishlist
> >
> > Hi,
> >
> > Would it be possible to get a newer version of nodejs in
> >
On Sun, Sep 20, 2020 at 02:36:44PM +0200, Jérémy Lal wrote:
> Le dim. 20 sept. 2020 à 12:00, Kurt Roeckx a écrit :
>
> > Package: nodejs
> > Severity: wishlist
> >
> > Hi,
> >
> > Would it be possible to get a newer version of nodejs in
> >
rmv4.S:3854: Error: bad arguments to instruction --
`orr r11,r12'
crypto/ec/ecp_nistz256-armv4.S:3855: Error: bad arguments to instruction --
`orrs r11,r14'
CLA: trivial
Fixes #12848
Reviewed-by: Tomas Mraz
Reviewed-by: Kurt Roeckx
GH: #12854
(cherry
viewed-by: Kurt Roeckx
GH: #12854
commit 08e9684c53deab7d815be47bfdf0f324a0d10ad9
Author: David Benjamin
Date: Fri Sep 18 15:21:43 2020 -0400
Deprecate ASN1_STRING_length_set in OpenSSL 3.0.
Fixes #12885
Reviewed-by: Kurt Roeckx
GH:
Package: nodejs
Severity: wishlist
Hi,
Would it be possible to get a newer version of nodejs in
buster-backports?
Kurt
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Package: nodejs
Severity: wishlist
Hi,
Would it be possible to get a newer version of nodejs in
buster-backports?
Kurt
On Fri, Sep 11, 2020 at 11:07:48AM +, Dr. Matthias St. Pierre wrote:
> For a more accurate and timely public overview over the current state of the
> blockers,
> it might be helpful to manage them via the 3.0.0 milestone
>
> https://github.com/openssl/openssl/milestone/15
>
> Some of the
The branch master has been updated
via 10203a34725ec75136b03d64fd2126b321419ac1 (commit)
from 8ae40cf57d2138af92a3479e23f35037ae8c5c30 (commit)
- Log -
commit 10203a34725ec75136b03d64fd2126b321419ac1
Author: Kurt
On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote:
> Please can anyone with PRs that they wish to have included in OpenSSL
> 3.0 beta1 ensure that they are merged to master by 8th September.
So that date has passed now. Can someone give an overview of what
we think is still needed to
On Fri, Aug 28, 2020 at 06:16:41PM +0200, Kurt Roeckx wrote:
> On Fri, Aug 28, 2020 at 04:55:56PM +0100, Brian Potkin wrote:
> >
> > ipp:/... is another URI for the printer. Execute
> >
> > lpadmin -p -v -E -m everywhere
>
> # lpadmin -p Brother_HL_L2370DN_s
On Fri, Aug 28, 2020 at 06:16:41PM +0200, Kurt Roeckx wrote:
> On Fri, Aug 28, 2020 at 04:55:56PM +0100, Brian Potkin wrote:
> >
> > ipp:/... is another URI for the printer. Execute
> >
> > lpadmin -p -v -E -m everywhere
>
> # lpadmin -p Brother_HL_L2370DN_s
On Fri, Aug 28, 2020 at 04:55:56PM +0100, Brian Potkin wrote:
>
> ipp:/... is another URI for the printer. Execute
>
> lpadmin -p -v -E -m everywhere
# lpadmin -p Brother_HL_L2370DN_series -v
ipp://BRN3C2AF4B40D45.local:631/ipp/print -E -m everywhere
lpadmin: Unable to connect to
On Fri, Aug 28, 2020 at 04:55:56PM +0100, Brian Potkin wrote:
>
> ipp:/... is another URI for the printer. Execute
>
> lpadmin -p -v -E -m everywhere
# lpadmin -p Brother_HL_L2370DN_series -v
ipp://BRN3C2AF4B40D45.local:631/ipp/print -E -m everywhere
lpadmin: Unable to connect to
On Fri, Aug 28, 2020 at 03:23:23PM +0100, Brian Potkin wrote:
> Thank you for your report, Kurt. Please provide the outputs of
>
intrepid:~# avahi-browse -rt _ipp._tcp
+ eth0 IPv6 EPSON WF-7515 Series @ intrepid Internet Printer
local
+ eth0 IPv6 Brother HL-L2370DN
On Fri, Aug 28, 2020 at 03:23:23PM +0100, Brian Potkin wrote:
> Thank you for your report, Kurt. Please provide the outputs of
>
intrepid:~# avahi-browse -rt _ipp._tcp
+ eth0 IPv6 EPSON WF-7515 Series @ intrepid Internet Printer
local
+ eth0 IPv6 Brother HL-L2370DN
Package: cups
Version: 2.3.3-2
Hi,
I've been trying to get printing on a Brother HL-L2370DN to work,
but all attempts failed so far.
I first attempted this the old way by adding a printer using the
adminstration page, where it finds it 3 times:
Brother HL-L2370DN series (Brother HL-L2370DN
Package: cups
Version: 2.3.3-2
Hi,
I've been trying to get printing on a Brother HL-L2370DN to work,
but all attempts failed so far.
I first attempted this the old way by adding a printer using the
adminstration page, where it finds it 3 times:
Brother HL-L2370DN series (Brother HL-L2370DN
On Mon, Aug 24, 2020 at 01:38:41PM -0700, John Baldwin wrote:
> On 8/18/20 9:49 AM, Matt Caswell wrote:
> >
> >
> > On 17/08/2020 18:55, John Baldwin wrote:
> >> 1) Is 'auth_level' supposed to work for this? The CHANGES.md change
> >>references SSL_CTX_set_security_level and openssl(1)
On Thu, Aug 13, 2020 at 12:43:01PM -0700, Ronald Crane via dev-security-policy
wrote:
> I'd argue that domain registrars, CAs, and hosting services _should_ have an
> obligation to deny services to obvious phishing domains. [1] (This is
> independent of what (if any) obligations they might
On Thu, Jul 23, 2020 at 02:35:28AM +0200, Jakob Bohm via openssl-users wrote:
> The OPENSSL_ia32cap_P variable, its bitfields and the code that sets
> it (in assembler) seemto have no clear documentation.
Have you seen the OPENSSL_ia32cap manpage?
Kurt
On Thu, Jul 16, 2020 at 03:57:17AM +0100, Dimitri John Ledkov wrote:
>
> openssl package could ship `.include /etc/ssl/providers.d/` in ssl.conf.
That would actually make sense.
We could use the include thing to ship a config file for the
fips module with the correct hash in it.
Kurt
On Tue, Jul 14, 2020 at 06:22:50PM +0100, Dimitri John Ledkov wrote:
> Package: libssl3
> Version: 3.0.0~~alpha4-1
> Severity: important
>
> Dear Maintainer,
>
> Please stop building legacy provider. None of the algorithms it
> provides are useful, or needed at all.
>
> Please do not not build
On Sun, Jul 12, 2020 at 12:29:43AM -0400, Viktor Dukhovni wrote:
>
> The main outstanding issue for which I'm authoring a new PR, is that
> each of the above results in SSL_CONF_cmd() returning an error for
> contexts of the other type or for contexts that are for a specific fixed
> version of
On Fri, Jul 03, 2020 at 12:51:19PM +, Salz, Rich via openssl-users wrote:
> * topic: Change some words by accepting PR#12089
>
> *
>
> * 4 against, 3 for, no absensions
>
> I am at a loss for words.
>
> I can’t contribute to a project that feels this way.
I would like to point
On Wed, Jul 01, 2020 at 10:39:18PM +0200, Vincent Delecroix wrote:
> Don't use ZZ as a base ring for your polynomial ring but Zmod(2**64).
>
> sage: R. = PolynomialRing(Zmod(2**64), 3)
> sage: x * 2**64
> 0
That doesn't actually work. The sum of 2 64 bit numbers is a 65
bit number. The
Hi,
I'm working on a project that reads an assembler file and converts that to
sage to help verify that the math the assembler is doing is correct. It's
to verify cryptographic implementations. Sage is only part of the
verification, other properties are checked using SMT.
What I did so far
notfixed 861572 1.14.4-2
reopen 861572
thanks
On Sun, Jun 21, 2020 at 01:21:22PM +0200, Antonio Radici wrote:
> Control: fixed -1 1.14.4-2
>
> On Sun, Apr 30, 2017 at 11:26:34PM +0200, Kurt Roeckx wrote:
> > Package: mutt
> > Version: 1.7.0-2
> >
> > The l
> tag 734234 +wontfix
> thanks
>
> Please check the status bar, that will show the information that you need.
I'm not sure what you mean here, but openssl isn't being used for
smime anymore, instead it's using gpg, and it now properly displays
who signed it.
The output you get now looks like:
On Fri, Jun 19, 2020 at 10:29:24PM +0100, Matt Caswell wrote:
>
> My immediate reaction to that is no - it shouldn't go to 1.1.1. That
> would impact a very high proportion of our user base.
So is risk an important factor? How do you judge the risk? By the
size of the change?
Kurt
On Thu, Jun 18, 2020 at 07:24:39PM +0200, Kurt Roeckx wrote:
>
> Now that a large fraction of the cost has been found, I can look
> again to see where the biggest cost in 3.0 comes from now and if we
> can do something about it.
So a code path that I've noticed before when looking at
On Thu, Jun 18, 2020 at 02:12:56PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I think that the default behavior should change for 3.0, and the API change
> described in the Release Notes. I find that alternative less impacting that
> this silent sudden performance deterioration.
Note that I
On Thu, Jun 18, 2020 at 10:41:40AM +0200, Tomas Mraz wrote:
> > I question the default behaviour, I think most people don't need
> > that support.
>
> Unfortunately that would be an API break that could be very hard to
> discover, so I do not think we can change this even in 3.0.
But I think the
going on.
>
> Over on an ntpsec list, Kurt Roeckx reported that he was still waiting...
>
> Richard's message said "I", so I sent him a copy off list. Correcting that...
So I took a look at at the EVP_PKEY case, and it seems we spend most
of our time doing:
- alloc/fre
On Wed, May 27, 2020 at 12:14:13PM +0100, Matt Caswell wrote:
> PR 10787 proposed to reduce the number of security bits for MD5 and SHA1
> in TLS (master branch only, i.e. OpenSSL 3.0):
>
> https://github.com/openssl/openssl/pull/10787
>
> This would have the impact of meaning that TLS < 1.2
On Mon, Jun 15, 2020 at 11:54:57PM -0700, Hal Murray via devel wrote:
>
> They are up to alpha3. I've been trying it.
>
> I added a tweak to wscript to support this, and some notes in HOWTO-OpenSSL
> That recipe also works for getting 1.1.1 on old systems so they can use NTS.
>
> -
>
Author: Sebastian Andrzej Siewior
Date: Sat Apr 25 23:57:00 2020 +0200
doc: Random spellchecking
A little spell checking.
Backport of commit
af0d413654d19 ("doc: Random spellchecking")
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: K
On Fri, Jun 12, 2020 at 05:10:11PM -0400, Mark Pearson wrote:
> Hi Kurt
>
> On 6/12/2020 2:58 PM, Kurt Roeckx wrote:
> > On Wed, Jun 03, 2020 at 01:39:08PM +, Mark Pearson wrote:
> > >
> > > The good - Lenovo are expanding what they offer on Linux (we ha
On Wed, Jun 03, 2020 at 01:39:08PM +, Mark Pearson wrote:
>
> The good - Lenovo are expanding what they offer on Linux (we had another big
> announcement yesterday about doing full config on our workstations with
> Ubuntu and RHEL). We're asking HW vendors to have Linux support upstream
>
On Thu, Jun 04, 2020 at 09:00:08AM -0700, John Baldwin wrote:
> At the moment there are 3 open PRs related to Kernel TLS offload
> support that I'm aware of:
>
> - 11589 adds TLS1.3 for Linux, has one approval from Matt Caswell
> - 10626 adds TLS1.3 for FreeBSD, from which 11589 is derived, but
On Fri, Jun 05, 2020 at 01:27:20PM +0200, Tomas Mraz wrote:
> Apparently the travis jobs are not getting started anymore for some
> reason.
>
> It happened to me on the GitHub linux-pam project and the solution (or
> workaround) was to migrate the project to the travis-ci.com.
>
> I just did it
The branch master has been updated
via 6985b0e3deaee2f6e83a670ce7b33cf9ee47933a (commit)
from 00da0f69890874feaa555fafb99b967b861e9118 (commit)
- Log -
commit 6985b0e3deaee2f6e83a670ce7b33cf9ee47933a
Author: Kurt
Just to clarify, as I understand it, openssl 1.0.2 (so libssl1.0.2
in oldstable) still has the problem, which means things like
libcurl in oldstable have that problem. And removing the
certificate from the trust store fixes it.
Kurt
Just to clarify, as I understand it, openssl 1.0.2 (so libssl1.0.2
in oldstable) still has the problem, which means things like
libcurl in oldstable have that problem. And removing the
certificate from the trust store fixes it.
Kurt
On Mon, Jun 01, 2020 at 01:29:39AM +0200, Axel Beckert wrote:
> OpenSSL 1.1.1g 21 Apr 2020
> → openssl s_client -connect mirror.sinavps.ch:443
> CONNECTED(0003)
> depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN =
> AddTrust External CA Root
> verify
On Mon, Jun 01, 2020 at 01:29:39AM +0200, Axel Beckert wrote:
> OpenSSL 1.1.1g 21 Apr 2020
> → openssl s_client -connect mirror.sinavps.ch:443
> CONNECTED(0003)
> depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN =
> AddTrust External CA Root
> verify
On Thu, Feb 21, 2019 at 05:33:25PM +0100, Celelibi wrote:
> Package: boolector
> Version: 1.5.118.6b56be4.121013-1+b1
> Severity: normal
>
> Dear Maintainer,
>
>
> Could you please consider upgrading the packaged version of boolector?
> I guess it was frozen to version 1.5.118 because of the
On Fri, May 22, 2020 at 10:38:34AM +0200, Hanno Böck via dev-security-policy
wrote:
> Just reported this to Chunghwa Telecom Co., Ltd.:
>
> --
>
> I'm contacting you about a problem with the certificate for
> *.hinet.net, as it can be found here [1].
>
> The Authority Information
On Thu, May 21, 2020 at 02:01:49PM -0700, Daniela Hood via dev-security-policy
wrote:
> Hello Sandy,
>
> GoDaddy received an email on Friday, May 7, 2020 12:06 UTC, reporting a key
> compromise, by Sandy. Once received our team started working on making sure
> that the certificate had indeed a
On Sat, May 16, 2020 at 10:04:24AM -0400, Andrew Ayer via dev-security-policy
wrote:
> On Sat, 16 May 2020 14:02:42 +0200
> Kurt Roeckx via dev-security-policy
> wrote:
>
> > https://crt.sh/?id=1902422627
> >
> > It's a certificate for api.pillowz.kz with the p
Hi,
Browsing crt.sh, I found this:
https://crt.sh/?id=1902422627
It's a certificate for api.pillowz.kz with the public key of Let's
Encrypt Authority X1 and X3 CAs.
It's revoked since 2020-01-31, but I couldn't find any incident
report related to it.
Kurt
On 2020-05-15 08:47, Peter Gutmann wrote:
Hanno Böck writes:
The impact it had was a monitoring system that checked whether the
certificate of a host was okay, using gnutls-cli with ocsp enabled (which
also uncovered a somewhat unexpected inconsistency in how the gnutls cli tool
behaves[1]).
On Mon, May 11, 2020 at 06:38:40PM +0300, Dmitry Belyavsky wrote:
> Dear Tomas,
>
> I'm not sure this is the best possible solution because it makes the
> application developers doing extra compile-time checks.
This is a very minimal change they they need to do that doesn't
have much risk.
But
On 2020-05-08 21:03, Wayne Thayer wrote:
It was recently reported [1] that IdenTrust experienced a multi-day OCSP
outage about two weeks ago. Other recent OCSP issues have resulted in
incident reports [3][4], so I am concerned that IdenTrust didn't report
this, and I created a bug [5] to ensure
On Fri, May 08, 2020 at 01:27:00PM +0300, Dmitry Belyavsky wrote:
> On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx wrote:
> >
> > So I think the suggestion is to have this:
> > - By default, SSL_ERROR_SSL is returned with
> > SSL_R_UNEXPECTED_EOF_WHILE_READING, the s
On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
> >
> > On 07/05/2020 12:22, Kurt Roeckx wrote:
> > > So I think we need at least to agree on:
> > > - Do we want an option that makes
On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote:
>
> Actually the coincidence is that the errno is set to 0 on EOF. So yes,
> we should explicitly clear the errno on EOF so any leftover value from
> previous calls does not affect this.
On EOF, errno is normally not modified. It's
On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote:
> From application developer side of view for protocols that do not
> depend on SSL detecting the truncation I think inventing a different
> behavior for this condition than the existing one as of 1.1.1f would be
> clearly wrong.
Hi,
We introduced a change in the 1.1.1e release that changed how we
handled an unexpected EOF. This broke various software which
resulted in the release of 1.1.1f that reverted that change.
In master we still have the 1.1.1e behaviour.
The change itself is small, it just calls SSLfatal() with a
On Wed, May 06, 2020 at 11:51:37PM +, Pedro David Marco wrote:
> Hi!
> Is it possible to make Postfix Reject instead of warn for "Illegal address
> syntax"?
So I've actually mailed about the same issue last week. As far as
I can see, postfix does reject it.
My case was with a space in the
On Fri, May 01, 2020 at 07:19:09PM +, Taylor R Campbell wrote:
> +.It Dv GRND_INSECURE
> +Do not block; instead fill
> +.Fa buf
> +with output derived from whatever is in the system entropy pool so
> +far.
> +Equivalent to reading from
> +.Pa /dev/urandom ;
> +see
> +.Xr rnd 4 .
> +.Pp
> +If
On Sun, May 03, 2020 at 12:05:22AM -0400, Thor Lancelot Simon wrote:
> On Sat, May 02, 2020 at 06:07:54PM +0200, Kurt Roeckx wrote:
> >
> > It's my understanding that it never blocks because the bootloader
> > provides entropy. Be time time the first user can call genentrop
On Sat, May 02, 2020 at 03:38:43PM +, Taylor R Campbell wrote:
> > Date: Sat, 2 May 2020 11:10:44 +0200
> > From: Kurt Roeckx
> >
> > On Fri, May 01, 2020 at 07:19:09PM +, Taylor R Campbell wrote:
> > >
> > > The alias getentropy(p,n) := getran
On Sat, May 02, 2020 at 04:31:43PM +, Taylor R Campbell wrote:
> > Date: Sat, 2 May 2020 18:07:54 +0200
> > From: Kurt Roeckx
> >
> > On Sat, May 02, 2020 at 03:38:43PM +, Taylor R Campbell wrote:
> > > > Date: Sat, 2 May 2020 11:10:44 +0200
> >
On Fri, May 01, 2020 at 07:19:09PM +, Taylor R Campbell wrote:
>
> The alias getentropy(p,n) := getrandom(p,n,GRND_INSECURE)
At several places in your document you imply this. But
getentropy(p,n) is more like getrandom(p,n,0). That is, it also
waits until it's seeded, it only blocks a single
Hi,
The log file shows:
postfix/submission/smtpd[28578]: warning: Illegal address syntax from
unknown[192.168.1.144] in RCPT command:
Where domain is in mydestination. There where other people in
To/Cc, but that user didn't get the email, nor did the sender get
any indication that that user
On Fri, Apr 24, 2020 at 01:26:05PM +0200, Yann Ylavic wrote:
>
> - DH_bits(dh) (used for logging only in httpd)
> Replaced by BN_num_bits(DH_get0_p(dh)).
> Not sure this one should be deprecated, it seems to be used in several
> places in openssl codebase still, no replacement?
I think the
On Wed, Apr 22, 2020 at 11:02:47AM +0200, Michael Tuexen wrote:
> > On 22. Apr 2020, at 10:38, Matt Caswell wrote:
> >
> >
> >
> > On 21/04/2020 23:45, Michael Tuexen wrote:
> >>> Looks like the failing call is here:
> >>>
> >>> if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
> >>>
On Tue, Apr 21, 2020 at 10:49:25PM +0100, Matt Caswell wrote:
>
> Looks like the failing call is here:
>
> if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
>(const void *), sizeof(on)) != 0) {
>
> To which we get an errno indicating "Invalid argument". So it looks
On Tue, Apr 21, 2020 at 09:18:05PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-04-15 13:38:23 [+0200], Kurt Roeckx wrote:
> > On Wed, Apr 15, 2020 at 12:19:24PM +0100, Simon McVittie wrote:
> > >
> > > I think setting defaults in the shared library itself
On Sun, Apr 19, 2020 at 03:38:45PM +0200, Mattia Rizzolo wrote:
> On Sun, Apr 19, 2020 at 02:18:16PM +0200, Debian Project Secretary - Kurt
> Roeckx wrote:
> > Stats for the DPL votes:
> > |--+--++---++-++---|
> > |
On Sun, Apr 19, 2020 at 04:06:14PM +0300, Adrian Bunk wrote:
> On Sun, Apr 19, 2020 at 02:18:16PM +0200, Debian Project Secretary - Kurt
> Roeckx wrote:
> >...
> > The details of the results are available at:
> > https://vote.debian.org/2020/vote_001
> >
|
|--+--++---++-++---|
Kurt Roeckx
Debian Project Secretary
signature.asc
Description: PGP signature
|
|--+--++---++-++---|
Kurt Roeckx
Debian Project Secretary
signature.asc
Description: PGP signature
On 2020-04-16 14:56, Neil Dunbar wrote:
I would have thought that an OCSP-stapling implementation which got an
OCSP status code 'successful' (0) with a 'revoked' status for the
certificate would want to pass that on to the client, replacing any
prior OCSP successful/status-good report,
On Wed, Apr 15, 2020 at 12:19:24PM +0100, Simon McVittie wrote:
>
> I think setting defaults in the shared library itself would be more
> robust, and if a configuration file to override that is necessary,
This is also the route that Ubuntu took, because it's possible to
install the library
Hi,
This is the first call for votes on the DPL election of 2020.
Voting period starts 2020-04-05 00:00:00 UTC
Votes must be received by 2020-04-18 23:59:59 UTC
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at
Hi,
This is the draft ballot.
Voting period starts 2020-04-05 00:00:00 UTC
Votes must be received by 2020-04-18 23:59:59 UTC
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting
On Tue, Mar 31, 2020 at 11:48:26PM +0200, Steffen Ullrich wrote:
> > You should fix your tests not to trigger an unexpected EOF. You
> > probably have code now that ignores the current error, you
> > shouldn't ignore that error, it's a real error.
>
> Fixing the tests to only consider an ideal
On Tue, Mar 31, 2020 at 11:48:26PM +0200, Steffen Ullrich wrote:
> > You should fix your tests not to trigger an unexpected EOF. You
> > probably have code now that ignores the current error, you
> > shouldn't ignore that error, it's a real error.
>
> Fixing the tests to only consider an ideal
On Tue, Mar 31, 2020 at 09:49:51PM +0200, Salvatore Bonaccorso wrote:
> Hi Kurt,
>
> On Tue, Mar 31, 2020 at 06:46:44PM +0200, Kurt Roeckx wrote:
> > On Tue, Mar 31, 2020 at 09:03:01AM +0200, Salvatore Bonaccorso wrote:
> > > On Sat, Mar 21, 2020 at 08:31:21PM +010
On Tue, Mar 31, 2020 at 09:49:51PM +0200, Salvatore Bonaccorso wrote:
> Hi Kurt,
>
> On Tue, Mar 31, 2020 at 06:46:44PM +0200, Kurt Roeckx wrote:
> > On Tue, Mar 31, 2020 at 09:03:01AM +0200, Salvatore Bonaccorso wrote:
> > > On Sat, Mar 21, 2020 at 08:31:21PM +010
On Tue, Mar 31, 2020 at 09:03:01AM +0200, Salvatore Bonaccorso wrote:
> On Sat, Mar 21, 2020 at 08:31:21PM +0100, gregor herrmann wrote:
> > On Fri, 20 Mar 2020 21:50:08 +0100, Sebastian Andrzej Siewior wrote:
> >
> > > The package FTBFS since openssl has been updated to 1.1.1e because the
> > >
On Tue, Mar 31, 2020 at 09:03:01AM +0200, Salvatore Bonaccorso wrote:
> On Sat, Mar 21, 2020 at 08:31:21PM +0100, gregor herrmann wrote:
> > On Fri, 20 Mar 2020 21:50:08 +0100, Sebastian Andrzej Siewior wrote:
> >
> > > The package FTBFS since openssl has been updated to 1.1.1e because the
> > >
On Wed, Mar 25, 2020 at 10:21:36PM -0700, Benjamin Kaduk wrote:
> I tihnk it's an interesting idea. To me, perhaps the most valuable part
> would be to accumulate a corpus of certificates/chains that are malformed
> or fail to validate due to a wide variety of errors, almost akin to a
> fuzzing
On 2020-03-19 07:02, Matt Palmer wrote:
2. If there are not explicit prohibitions already in place, *should* there
be? If so, should it be a BR thing, or a Policy thing?
I think there should be. I expect them to publish a CRL that says the
reason for revocation is a key compromise. I
On Wed, Mar 18, 2020 at 11:03:42AM +, Dat Le wrote:
> Hi,
>
> I'm not sure if this is the right place to ask, I'm sorry if not. I just see
> this email as the maintainer contact of official openssl package on Ubuntu
> 18.04.
>
> My issue:
> I am investigate openssl to apply it to encrypt
We're now into the campaigning period. We have 5 candidates this
year:
- Jonathan Carter
- Sruthi Chandran
- Brian Gupta
I will make the platforms available when I have received them.
Kurt Roeckx
Debian Project Secretary
signature.asc
Description: PGP signature
On Thu, Mar 12, 2020 at 08:54:16AM -0400, Sam Hartman wrote:
>
> I'm concerned that by sending my longish message about why I am not
> running, I may have started a trend that I do not value.
> Typically the nomination messages are fairly short.
> I appreciate Jonathan's thoughtful message, but
On Thu, Mar 12, 2020 at 02:23:54AM -0700, Hal Murray wrote:
> If all goes well, the NTS-KE step is very rare. The client gets 8 cookies.
> Each NTP exchange uses a cookie and gets back a new cookie. If an occasional
> packet is lost, the client can ask for extras. The NTP side just keeps
>
On Thu, Mar 12, 2020 at 08:44:33AM +0100, Miroslav Lichvar wrote:
> There is a different problem that might need to be addressed first.
> MITM attackers could circumvent NTS simply by joining the pool. How
> could that be prevented or minimized? Not accept any new members and
> trust the old ones
On Wed, Mar 11, 2020 at 02:30:11PM -0700, Hal Murray wrote:
>
> Any thoughts about how to get the pool to support it?
I think that if we want to use NTS with the pool, that we need a
secure way of getting the list of servers. That probably means
either DNSSEC or TLS. Both have their advantages
On Wed, Mar 11, 2020 at 12:15:32PM +, Matt Caswell wrote:
>
> Debian 10 omits all the SHA1 entries from the above list. Note that
> Debian 10 will only allow SHA1 if the security level is explicitly set
> to 0 (via the -cipher "DEFAULT:@SECLEVEL=0" command line arg). Probably
> because the
On Wed, Mar 11, 2020 at 12:15:32PM +, Matt Caswell wrote:
>
> I *think* what is happening is the server is checking the chain it has
> been configured with, spotting that it includes a SHA1 based signature
> and therefore refusing to respond at all because the client has not
> indicated SHA1
Package: zfs-auto-snapshot
Version: 1.2.4-2
Hi,
The manpage documents that you can set com.sun:auto-snapshot to
false to disable the auto snapshot, and that you can use
--default-exclude to reverse that behaviour. But --default-exclude
doesn't seem to have any effect.
When running:
#
round 2020-03-22.
Details and results for the vote will be published at:
http://www.debian.org/vote/2020/vote_001
Please make sure that nominations are sent to (or cc:'d to)
debian-vote, and are cryptographically signed.
Kurt Roeckx
Debian Project Secretary
signature.asc
Description: PGP signature
On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
>
>
> On 28/02/2020 23:43, Dr Paul Dale wrote:
> > Any suggestions for a consensus on this thread?
>
> I think we can probably agree that:
>
> - Command option deprecations should be handled better
> - We should look at whether we
On Thu, Feb 27, 2020 at 01:23:16PM +, Salz, Rich wrote:
> Tony Arceri sent me a pure-CSS solution that worked and looked similar.
I was about to mention that the website it just text+css.
Kurt
On Fri, Feb 21, 2020 at 11:27:55PM +, Matt Caswell wrote:
>
>
> On 21/02/2020 23:18, Kurt Roeckx wrote:
> > On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
> >>
> >> dhparam itself has been deprecated. For that reason we are not
> &g
On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
>
> dhparam itself has been deprecated. For that reason we are not
> attempting to rewrite it to use non-deprecated APIs. The informed
> decision we have made about DH_check use in dhparam is to not build the
> whole application in a
501 - 600 of 14770 matches
Mail list logo
