On Sat, Mar 30, 2019 at 08:05:41PM -0700, Hal Murray wrote:
> > A sockaddr is not meant to store the address, ...
>
> But the API wants a sockaddr.
>int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
> There is no hint in the man page that an IPv6 address won't fit.
>
>
On Sat, Mar 30, 2019 at 02:35:18PM -0700, Hal Murray via devel wrote:
> I just pushed a fix. It was an interesting quirk. The API for accepet
> includes a pointer and length to a place to put the IP Address of the remote
> site. The type of that place is struct sockaddr. sockaddr is generic,
On Sat, Mar 30, 2019 at 01:33:33PM +0700, Martin Michlmayr wrote:
> * Kurt Roeckx [2019-03-29 23:39]:
> > I've updated the vote pages to remove you as candidate.
>
> I'm not sure if removing Simon from the vote page entirely is best
> from a historical records point of view.
On Thu, Mar 28, 2019 at 09:25:58PM +0100, Simon Richter wrote:
> Hi,
>
> On 17.03.19 00:51, Simon Richter wrote:
>
> > I'd also like nominate myself for the 2019 DPL election.
>
> As you may have noticed, life happened to me shortly after sending that
> mail. I'm definitely not in a position to
On Mon, Mar 25, 2019 at 04:00:23AM -0700, Hal Murray via devel wrote:
>
> I thought it had been removed.
>
> Job #183497467 ( https://gitlab.com/NTPsec/ntpsec/-/jobs/183497467 )
>
> Stage: build
> Name: debian-oldoldstable-refclocks
> Trace: Err http://deb.debian.org oldoldstable-updates/main
On Tue, Mar 19, 2019 at 11:21:19PM +0100, Holger Weiß wrote:
> * Kurt Roeckx [2019-03-19 22:59]:
> > On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote:
> > > Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹
> > > unexpectedly returns NULL
On Tue, Mar 19, 2019 at 11:21:19PM +0100, Holger Weiß wrote:
> * Kurt Roeckx [2019-03-19 22:59]:
> > On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote:
> > > Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹
> > > unexpectedly returns NULL
On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote:
> Just for the record:
>
> * Sebastian Andrzej Siewior [2018-11-05 00:28]:
> > It is a TLS1.3 issue. If I limit max protocol to TLS1.2 then the
> > testsuite passes.
>
> Yes, it's an OpenSSL bug. If TLSv1.3 is used,
On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote:
> Just for the record:
>
> * Sebastian Andrzej Siewior [2018-11-05 00:28]:
> > It is a TLS1.3 issue. If I limit max protocol to TLS1.2 then the
> > testsuite passes.
>
> Yes, it's an OpenSSL bug. If TLSv1.3 is used,
On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via dev-security-policy
wrote:
>
> When a value in column E is 100%, this is pretty solid evidence of
> noncompliance with BR 7.1.
> When the values in column E and G are both approximately 50%, this
> suggests (but does not prove) that
On Mon, Mar 18, 2019 at 01:55:50PM +0900, Atsuhito Kohda wrote:
> Hi Kurt,
>
> > So from what I understand, the problem is really on the dovecot
> > side. What does dovecot's log show?
> >
> > Dovecot can configure DH, which seems to default to:
> > ssl_dh = >
> > That file should be fine,
We're now into the campaigning period. We have 5 candidates this
year:
- Joerg Jaspert
- Jonathan Carter
- Sam Hartman
- Martin Michlmayr
- Simon Richter
I will make his platforms available when I have received them.
Kurt Roeckx
Debian Project Secretary
signature.asc
Description: PGP
On Sun, Mar 17, 2019 at 12:51:27AM +0100, Simon Richter wrote:
> Hi,
>
> I'd also like nominate myself for the 2019 DPL election.
This looks like a valid nomination
Kurt
On Sun, Mar 17, 2019 at 12:36:31AM +0800, Martin Michlmayr wrote:
> I hereby announce my intention to run for DPL.
I'm going to look at this as a valid self nomination, and
not just an intention to nominate yourself.
Kurt
On Sat, Mar 16, 2019 at 09:06:06AM +0900, Atsuhito Kohda wrote:
> Hi Sebastian,
>
> On Fri, 15 Mar 2019 22:08:13 +0100, Sebastian Andrzej Siewior wrote:
>
> > Do you have somewhere more information what failed on the fetchmail
> > side?
>
> Yes, I have error messages of fetchmail but they
On Thu, Mar 14, 2019 at 04:09:10PM -0700, Jaime Hablutzel via
dev-security-policy wrote:
> > In accordance with our conversations to date, prior to 3/7 6:30pm AZ we
> > utilized raw 64 bit output from CSPRING, with uniqueness and non zero
> > checks. This new understanding of the rules calls
On Thu, Mar 14, 2019 at 09:38:52AM -0400, Sam Hartman wrote:
>
> I nominate myself to stand as a candidate for DPL in the 2019 DPL
> elections.
I ack that this is valid.
Kurt
On Thu, Mar 14, 2019 at 12:34:02PM +0100, Joerg Jaspert wrote:
> I hereby nominate myself for the DPL election 2019.
I ack that this is valid.
Kurt
On Thu, Mar 14, 2019 at 01:43:04PM +0200, Jonathan Carter wrote:
> I hereby nominate myself for the 2019 DPL election.
I ack that this is valid.
Kurt
On Wed, Mar 13, 2019 at 05:56:55AM +0900, Hector Martin 'marcan' via
dev-security-policy wrote:
> On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote:
> > Note that even 7 bytes or less may still be valid - for example, if the
> > randomly generated integer was 4 [1], you might only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 10 Mar 2019 16:51:27 +0100
Source: madplay
Architecture: source
Version: 0.15.2b-9
Distribution: unstable
Urgency: medium
Maintainer: Kurt Roeckx
Changed-By: Kurt Roeckx
Changes:
madplay (0.15.2b-9) unstable; urgency=medium
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 10 Mar 2019 16:42:14 +0100
Source: libmad
Architecture: source
Version: 0.15.1b-10
Distribution: unstable
Urgency: medium
Maintainer: Kurt Roeckx
Changed-By: Kurt Roeckx
Closes: 899582
Changes:
libmad (0.15.1b-10) unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 10 Mar 2019 16:35:25 +0100
Source: libid3tag
Architecture: source
Version: 0.15.1b-14
Distribution: unstable
Urgency: medium
Maintainer: Kurt Roeckx
Changed-By: Kurt Roeckx
Closes: 899861
Changes:
libid3tag (0.15.1b-14
On Sun, Mar 10, 2019 at 02:20:45PM +, Steve McIntyre wrote:
> Hi!
>
> I don't know if you've even seen this RC bug. Could you please update
> the maintainer address to point to something that works?
I never got an email to the -owner address, so I couldn't migrate
it. I assume our CVS
On Sun, Mar 10, 2019 at 02:20:45PM +, Steve McIntyre wrote:
> Hi!
>
> I don't know if you've even seen this RC bug. Could you please update
> the maintainer address to point to something that works?
I never got an email to the -owner address, so I couldn't migrate
it. I assume our CVS
On Sun, Mar 10, 2019 at 01:48:23PM +0100, Joerg Jaspert wrote:
> On 15337 March 1977, Sam Hartman wrote:
>
> > In fairness, I'd recommend that the nominations period be extended for
> > some explicit time. I think that we want to have a known window for new
> > nominations rather than say
On Sun, Mar 10, 2019 at 01:48:23PM +0100, Joerg Jaspert wrote:
> On 15337 March 1977, Sam Hartman wrote:
>
> > In fairness, I'd recommend that the nominations period be extended for
> > some explicit time. I think that we want to have a known window for new
> > nominations rather than say
| Saturday 2019-03-16 |
| Campaign | Sunday 2019-03-17 | Saturday 2019-04-06 |
| Vote | Sunday 2019-04-07 | Saturday 2019-04-20 |
Kurt Roeckx
Debian Project Secretary
On Sun, Mar 03, 2019 at 01:17:23AM +0100, Debian Project Secretary - Kurt
Roeckx wrote:
>
> Hi,
>
&g
: Debian OpenSSL Team
Changed-By: Kurt Roeckx
Description:
libcrypto1.0.2-udeb - Secure Sockets Layer toolkit - libcrypto udeb (udeb)
libssl1.0-dev - Secure Sockets Layer toolkit - development files
libssl1.0.2 - Secure Sockets Layer toolkit - shared libraries
libssl1.0.2-udeb - ssl shared library
On Sun, Mar 03, 2019 at 03:30:53PM -0800, Gary E. Miller via devel wrote:
> Yo Kurt!
>
> On Mon, 4 Mar 2019 00:19:44 +0100
> Kurt Roeckx via devel wrote:
>
> > > Actually getting timestamps from the NIC is fairly involved. The NIC
> > > has its own clock
On Sun, Mar 03, 2019 at 05:59:11PM -0500, Daniel Franke wrote:
> On Sun, Mar 3, 2019 at 8:45 AM Kurt Roeckx via devel wrote:
> > On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote:
> > >
> > > k...@roeckx.be said:
> > > > If this is something y
On Sun, Mar 03, 2019 at 10:25:31PM +0100, Achim Gratz via devel wrote:
> Kurt Roeckx via devel writes:
> > I don't see how it can work with the current pool system. You look
> > something up like pool.ntp.org and get some IP addresses. But none
> > of those will have a certifi
On Sun, Mar 03, 2019 at 08:19:44PM +, Ben Hutchings wrote:
> On Sun, 2019-03-03 at 18:59 +0100, Kurt Roeckx wrote:
> [...]
> > Most people will actually have at least 2 hardware RNGs: One in
> > the CPU and one in the TPM. We can make the kernel trust those as
> > entr
On Sun, Mar 03, 2019 at 08:56:55PM +0100, Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> > There is no security in the pool anyway, so let's put that discussion
> > aside for a while.
>
> I'd take exception with that statement. If the pool was upgraded to use
> NTS one way or the
I think the only sane things are:
- Use a hardware RNG (CPU, TPM, chaos key, ...)
- Credit a seed file stored during the previous boot
- Wait for new entropy from other sources
Note that is can be a combination of all 3.
We currently do not credit the seed file, for various good
reasons. We
On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote:
>
> k...@roeckx.be said:
> > If this is something you're worried about, this can be solved with the
> > interleave mode, which was removed.
>
> How well does it work?
It works great, the errors are much smaller when it's enabled.
>
On Sat, Mar 02, 2019 at 09:23:51PM -0800, Hal Murray via devel wrote:
> *) There is actually one interesting point that authentication makes more
> interesting. On receive, we get a time stamp when the packet arrives. We
> can
> take all day to inspect the packet and run authentication code.
e campaign period, so I can publish them
around 2019-03-17.
Details and results for the vote will be published at:
http://www.debian.org/vote/2019/vote_001
Please make sure that nominations are sent to (or cc:'d to)
debian-vote, and are cryptographically signed.
Kurt Roeckx
Debian Project
On Thu, Feb 28, 2019 at 11:50:52AM -0700, James Pooton wrote:
> qemu: Unsupported syscall: 382
I can't find what syscall 382 should be, it seems to be higher
than all the numbers I can find, the higest number is 294.
Can you give combination of ca-certificates / openssl that works
/ fails?
OpenSSL Team
Changed-By: Kurt Roeckx
Description:
libcrypto1.1-udeb - Secure Sockets Layer toolkit - libcrypto udeb (udeb)
libssl-dev - Secure Sockets Layer toolkit - development files
libssl-doc - Secure Sockets Layer toolkit - development documentation
libssl1.1 - Secure Sockets Layer toolkit
Package: postfix
Version: 3.3.2-1
Hi,
It seems that by default smtp_tls_CApath is not set, which means
by default postfix can't check that certificates are valid. Please
set the default to /etc/certs/ssl, and add a Depends or Recommends
on ca-certificates.
Kurt
On Sat, Feb 23, 2019 at 02:07:38PM +0400, Scott Rea via dev-security-policy
wrote:
> G’day Wayne et al,
>
> In response to your post overnight (included below), I want to assure you
> that DarkMatter’s work is solely focused on defensive cyber security, secure
> communications and digital
On Fri, Feb 22, 2019 at 03:45:39PM -0800, cooperq--- via dev-security-policy
wrote:
> On Friday, February 22, 2019 at 2:37:20 PM UTC-8, Jonathan Rudenberg wrote:
> > With regards to the broader question, I believe that DarkMatter's alleged
> > involvement with hacking campaigns is incompatible
-
commit 32d40d0d8942ac7156066c55354dc174f7b8b3bc
Author: Kurt Roeckx
Date: Tue Feb 19 20:29:53 2019 +0100
Make sure that generated POD files are actually created before we run
doc-nits
Reviewed-by: Richard Levitte
GH: #8285
commit a9d2d52ed1b56a72e6dd0e24357dea0bb84c3550
Author
The branch OpenSSL_1_1_1-stable has been updated
via 5cd8faed79694d8ad8f1db2d02dd7c06fa338dd9 (commit)
from a9b9d2654b974f7b2732b9a08e975b1a396efb31 (commit)
- Log -
commit 5cd8faed79694d8ad8f1db2d02dd7c06fa338dd9
The branch master has been updated
via e3ac3654892246d7492f1012897e42ad7efd13ce (commit)
from 70680262329004c934497040bfc6940072043f48 (commit)
- Log -
commit e3ac3654892246d7492f1012897e42ad7efd13ce
Author: Vedran
The branch master has been updated
via 70680262329004c934497040bfc6940072043f48 (commit)
from e09633107b7e987b2179850715ba60d8fb069278 (commit)
- Log -
commit 70680262329004c934497040bfc6940072043f48
Author: Jan Macku
The branch OpenSSL_1_1_1-stable has been updated
via a9b9d2654b974f7b2732b9a08e975b1a396efb31 (commit)
from 2e826078410bdb117710890b0e99bbdbbbf7e95d (commit)
- Log -
commit a9b9d2654b974f7b2732b9a08e975b1a396efb31
The branch OpenSSL_1_1_1-stable has been updated
via 2e826078410bdb117710890b0e99bbdbbbf7e95d (commit)
via 2086edb799acf6ad5ef0bb53aa3b17abf4f7f992 (commit)
from ed48d2032d29a82c6aebbddf0fbf530ac2d2521d (commit)
- Log
The branch master has been updated
via e09633107b7e987b2179850715ba60d8fb069278 (commit)
via c0e8e5007ba5234d4d448e82a1567e0c4467e629 (commit)
from 8f58ede09572dcc6a7e6c01280dd348240199568 (commit)
- Log -
On Wed, Jan 23, 2019 at 07:54:57PM +0100, Kurt Roeckx wrote:
>
> But those pass at least run-backtrace-native: arm64, armel, armhf,
> i386, ppc64el, s390x, powerpc, ppc64, sparc64
>
> This means that for the arches we release for, mips* is the only
> one that does not pass ru
On Wed, Jan 23, 2019 at 07:54:57PM +0100, Kurt Roeckx wrote:
>
> But those pass at least run-backtrace-native: arm64, armel, armhf,
> i386, ppc64el, s390x, powerpc, ppc64, sparc64
>
> This means that for the arches we release for, mips* is the only
> one that does not pass ru
Hi,
This is the proposed timeline for the 2019 DPL election:
Nomination period: Sunday 2019-03-03 - Saturday 2019-03-09
Campaigning period: Sunday 2019-03-10 - Saturday 2019-03-30
Voting period: Sunday 2019-03-31 - Saturday 2019-04-13
Kurt
Hi,
This is the proposed timeline for the 2019 DPL election:
Nomination period: Sunday 2019-03-03 - Saturday 2019-03-09
Campaigning period: Sunday 2019-03-10 - Saturday 2019-03-30
Voting period: Sunday 2019-03-31 - Saturday 2019-04-13
Kurt
Package: wml
Version: 2.12.2~ds1-1
Severity: serious
Hi,
I'm getting the following error:
Can't locate GD.pm in @INC (you may need to install the GD module) (@INC
contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1
/usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28
Package: wml
Version: 2.12.2~ds1-1
Severity: serious
Hi,
I'm getting the following error:
Can't locate GD.pm in @INC (you may need to install the GD module) (@INC
contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1
/usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 16 Feb 2019 14:54:50 +0100
Source: elfutils
Binary: elfutils libelf1 libelf-dev libdw-dev libdw1 libasm1 libasm-dev
Architecture: source
Version: 0.176-1
Distribution: unstable
Urgency: medium
Maintainer: Kurt Roeckx
Changed
On 2019-02-08 1:04, identr...@gmail.com wrote:
On Thursday, February 7, 2019 at 6:47:03 PM UTC-5, iden...@gmail.com wrote:
On 04/04/2018 we found a discrepancy in the address values for some SSL
certificates. A formal incident Report was just posted:
On Wed, Feb 06, 2019 at 10:31:39PM -0800, Hal Murray wrote:
>
> k...@roeckx.be said:
> > Please use 0 instead of TLS_MAX_VERSION, it means the same. I've marked
> > TLS_MAX_VERSION for deprecation.
>
> Thanks for the heads up.
>
> Is there any documentation on that? (man page?)
There is
On Thu, Jan 31, 2019 at 02:19:28PM -0600, David Benjamin wrote:
> On Thu, Jan 31, 2019 at 2:01 PM Matt Caswell wrote:
>
> >
> > On 31/01/2019 18:50, David Benjamin wrote:
> > > We will see if this damage turns out fatal for KeyUpdate, but OpenSSL
> > can at
> > > least help slow its spread by
On Wed, Feb 06, 2019 at 02:05:27PM -0800, Hal Murray via devel wrote:
>
> float mintls = 1.2; /* minimum TLS version allowed */
> float maxtls; /* maximum TLS version allowed */
>
> Floats? The API to OpenSSL doesn't work in floats. We'll have to translate
>
On 2019-02-04 21:33, Kathleen Wilson wrote:
All,
As you know, CCADB sends audit reminder emails regarding root certs in
Mozilla's program on the 3rd Tuesday of each month.
We are going to update the date checks for determining when the email
gets sent, so that rather than keying off of the
On Sun, Feb 03, 2019 at 03:15:55PM -0600, Richard Laager via devel wrote:
> On 2/3/19 1:01 PM, Eric S. Raymond wrote:
> > I guess it will have to be an empty string that disables encryption.
>
> I'm not sure if you wrote this before the recent messages on the NULL
> ciphers. But you said you were
On Sat, Feb 02, 2019 at 05:52:25PM -0500, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
> > On Sat, 2 Feb 2019 06:16:45 -0500 (EST)
> > "Eric S. Raymond via devel" wrote:
> >
> > > NEVER CONFIGURE WHAT YOU CAN DISCOVER
> > >
> > > These are from nts.adoc:
> > >
> > >
On Fri, Feb 01, 2019 at 03:02:17PM -0700, Wayne Thayer wrote:
> It was pointed out to me that the OCSP status of the misissued certificate
> that is valid for over 5 years is still "unknown" despite having been
> revoked a week ago. I asked KIR about this in the bug [1] and am surprised
> by their
On Tue, Jan 29, 2019 at 02:07:09PM +, Matt Caswell wrote:
> So I plan to start the vote soon for merging PR#8096 and backporting it to
> 1.1.1. This is a breaking change as previously discussed.
>
> My proposed vote text is as follows. Please let me know asap of any feedback.
> Otherwise I
On Tue, Jan 29, 2019 at 02:42:48PM -0500, Viktor Dukhovni wrote:
> > On Jan 29, 2019, at 2:23 PM, Rich Fought wrote:
> >
> > The OpenSSL 1.1.1 ciphers manpage claims that some non-ephemeral DH ciphers
> > are supported:
> >
> > TLS1.0:
> > DH-RSA-AES128-SHA
> > DH-RSA-AES256-SHA
>
> The
On Tue, Jan 29, 2019 at 01:27:24PM -0600, David Benjamin wrote:
> I think one clear conclusion from this incident is that this sort of
> low-level API should be avoided, or people will use them in finicky ways
> that break unexpectedly when you change things. Better defer such
> mechanisms to when
On Tue, Jan 29, 2019 at 02:07:09PM +, Matt Caswell wrote:
> So I plan to start the vote soon for merging PR#8096 and backporting it to
> 1.1.1. This is a breaking change as previously discussed.
>
> My proposed vote text is as follows. Please let me know asap of any feedback.
> Otherwise I
On 2019-01-29 1:29, Wayne Thayer wrote:
Piotr just filed an incident report on the misissuance that was reported on
18-January: https://bugzilla.mozilla.org/show_bug.cgi?id=1523186
I guess this part is not very clear to me:
> We identified and removed from system the registration policy that
On Mon, Jan 28, 2019 at 03:38:50PM +, Matt Caswell wrote:
>
>
> On 24/01/2019 18:12, Sam Roberts wrote:
> > The other changes that TLS1.3 requires, multiple session tickets, a
> > few new APIs to replace some of the SSL_renegotiate use-cases, etc.,
> > all are pretty routine. We could get
On Sun, Jan 27, 2019 at 08:33:06PM +1000, Tim Hudson wrote:
> From https://github.com/openssl/openssl/pull/7721
>
> Tim - I think inline functions in public header files simply shouldn't be
> present.
> Matt - I agree
> Richard - I'm ambivalent... in the case of stack and lhash, the generated
>
On Thu, Jan 24, 2019 at 11:09:40PM +0700, Arran Cudbard-Bell wrote:
> We could use this to determine what SSL_ERROR_WANT_READ is indicating. As it
> seems SSL_ERROR_WANT_READ could indicate two conditions in this scenario:
>
> 1) No pending bytes - Additional handshake messages were processed,
Package: python3-twisted
Version: 17.4.0-2
Severity: serious
Hi,
When using python3-twisted from backports (18.7.0-2~bpo9+1), I get
the following error:
Traceback (most recent call last):
File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File
Package: python3-twisted
Version: 17.4.0-2
Severity: serious
Hi,
When using python3-twisted from backports (18.7.0-2~bpo9+1), I get
the following error:
Traceback (most recent call last):
File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File
Package: python3-twisted
Version: 17.4.0-2
Severity: serious
Hi,
When using python3-twisted from backports (18.7.0-2~bpo9+1), I get
the following error:
Traceback (most recent call last):
File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File
On 2019-01-24 20:19, Tim Hollebeek wrote:
I think the assertion that the commonName has anything to do with what the
user would type and expect to see is unsupported by any of the relevant
standards, and as Rob noted, having it be different from the SAN strings is
not in compliance with the
On 2019-01-24 15:41, Rob Stradling wrote:
Here's an example cert containing the A-label in the SAN:dNSName and the
U-label in the CN. (It was issued by Sectigo, known back then as Comodo
CA, before we switched to always putting the A-label in the CN):
On 2019-01-24 12:08, Rob Stradling wrote:
Hi Kurt.
BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
address or Fully-Qualified Domain Name that is one of the values
contained in the Certificate’s subjectAltName extension (see Section
7.1.4.2.1)."
Fitting the U-label
On 2019-01-24 9:47, Buschart, Rufus wrote:
Good morning!
I would like to sharpen my argument from below a little bit: If a CA gets a
request to issue a certificate for the domain xn--gau-7ka.siemens.de, how can
the CA tell, that xn--gau-7ka is a punycode string in IDNA2008 and not only a
reopen 746426
reassign 746426 gcc-8
thanks
On Wed, Jan 23, 2019 at 03:32:32PM +0100, Mark Wielaard wrote:
> Hi Kurt,
>
> I saw Debian Bug#746426 was recently closed.
> You originally wrote:
>
> > It seems that not all arches have -fasynchronous-unwind-tables
> > enabled. I see it enabled on
On Tue, Jan 22, 2019 at 02:48:26PM -0500, Viktor Dukhovni wrote:
> As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure
> what to do there, but perhaps we could define a new even for keyUpdates
> that does not mislead applications into assuming a new "handshake".
I think
On Fri, Jan 18, 2019 at 06:40:05PM -0500, Dennis Clarke wrote:
> On 1/18/19 1:53 AM, Dennis Clarke wrote:
> >
> > Going in circles trying to compile 1.1.1a with strict C99 and no
> > optimizations and with a ready to debug and single step resultant
> > library.
>
> Ignore all this. Thou shalt
On Sat, Jan 19, 2019 at 12:24:45PM +0300, sergio wrote:
> On Fri, 18 Jan 2019 23:02:28 +0100 Kurt Roeckx wrote:
>
> > You have python3-msgpack (>= 0.3.0), while it should be be >= 0.4.2.
>
>
> The python3-msgpack dependency is absent.
>
> % apt s
On Sat, Jan 19, 2019 at 12:24:45PM +0300, sergio wrote:
> On Fri, 18 Jan 2019 23:02:28 +0100 Kurt Roeckx wrote:
>
> > You have python3-msgpack (>= 0.3.0), while it should be be >= 0.4.2.
>
>
> The python3-msgpack dependency is absent.
>
> % apt s
On Fri, Jan 18, 2019 at 10:34:36PM +0100, Andrej Shadura wrote:
> Hi,
>
> On Fri, 18 Jan 2019 at 22:15, Kurt Roeckx wrote:
> > On Fri, Jan 18, 2019 at 08:49:01PM +0100, Andrej Shadura wrote:
> > > found 919707 0.34.1.1-2~bpo9+1
> > > notfound 919707 0.34.1.1-2
&
On Fri, Jan 18, 2019 at 10:34:36PM +0100, Andrej Shadura wrote:
> Hi,
>
> On Fri, 18 Jan 2019 at 22:15, Kurt Roeckx wrote:
> > On Fri, Jan 18, 2019 at 08:49:01PM +0100, Andrej Shadura wrote:
> > > found 919707 0.34.1.1-2~bpo9+1
> > > notfound 919707 0.34.1.1-2
&
On Fri, Jan 18, 2019 at 08:49:01PM +0100, Andrej Shadura wrote:
> found 919707 0.34.1.1-2~bpo9+1
> notfound 919707 0.34.1.1-2
I believe the version I've set it to was the correct version, even
when I did find the problem in backports, the problem really exist
is both testing and
On Fri, Jan 18, 2019 at 08:49:01PM +0100, Andrej Shadura wrote:
> found 919707 0.34.1.1-2~bpo9+1
> notfound 919707 0.34.1.1-2
I believe the version I've set it to was the correct version, even
when I did find the problem in backports, the problem really exist
is both testing and
Package: matrix-synapse
Version: 0.34.1.1-2
Severity: serious
Hi,
When installing the version in stretch-backports, I get:
-- Unit matrix-synapse.service has begun starting up.
Jan 18 19:07:18 mirror python3[25438]: ERROR:root:Needed pymacaroons>=0.9.3,
got pymacaroons==0.9.2
Jan 18 19:07:18
Package: matrix-synapse
Version: 0.34.1.1-2
Severity: serious
Hi,
When installing the version in stretch-backports, I get:
-- Unit matrix-synapse.service has begun starting up.
Jan 18 19:07:18 mirror python3[25438]: ERROR:root:Needed pymacaroons>=0.9.3,
got pymacaroons==0.9.2
Jan 18 19:07:18
Package: matrix-synpase
Hi,
It seems that at least version 0.34.0-3~bpo9+2 logs everything to
/var/log/messages, and also to
/var/log/matrix-synapse/homeserver.log
/var/log/messages is currently a 1.3 GB file, containing data for
about 1 day. /var/log/matrix-synapse/homeserver.log on the other
On Sat, Jan 12, 2019 at 05:06:18PM -0800, Jim Wilson wrote:
> On Sat, Jan 12, 2019 at 3:21 PM Kurt Roeckx wrote:
> > > But how many are actually used? Which does Debian support?
> >
> > I'm not at all an export of mips, I really don't know that much
> > about it.
&g
On Sat, Jan 12, 2019 at 11:35:48PM +0100, Mark Wielaard wrote:
> On Sat, 2019-01-12 at 00:23 +0100, Kurt Roeckx wrote:
> > I've been looking at mips, and it seems to have many different
> > ABIs too. A patch I've received does this:
> > int
> > mips_return_value_locat
On Tue, Jan 08, 2019 at 02:52:33PM +0100, Mark Wielaard wrote:
> > There is a problem here though. The riscv support was written to try
> > to handle both 32-bit and 64-bit targets with a single elfutils
> > backend. But I have 6 ABIs I need to (theoretically) handle in
> > riscv_retval.c. The
On Thu, Jan 10, 2019 at 09:43:27AM +0100, Kurt Roeckx wrote:
> On Wed, Jan 09, 2019 at 11:53:38PM +0100, Karsten Merker wrote:
> > > So while I agree there might be possible improvements in how the vote
> > > goes, I
> > > don't think just deleting that one
On Wed, Jan 09, 2019 at 11:53:38PM +0100, Karsten Merker wrote:
> > So while I agree there might be possible improvements in how the vote goes,
> > I
> > don't think just deleting that one sentence is it.
>
> I beg to differ :). I have taken a look at Ian's proposal with
> using sqrt(people
On Wed, Jan 09, 2019 at 07:28:34PM +0100, Luke Faraone wrote:
> On Wed, 9 Jan 2019 at 19:07, Pierre-Elliott Bécue wrote:
> > Le 9 janvier 2019 16:49:30 GMT+01:00, Kurt Roeckx a écrit :
> > >I would try to use software that can run a vote like that,
> > >where it'
On Wed, Jan 09, 2019 at 04:28:41PM +0100, Thomas Goirand wrote:
>
> Would this vote be secret? In some situation, I'd rather not vote than
> having my vote disclosed. I'm very much OK for the secretary to see what
> I voted for though.
The voting would be secret. I think the only output should
On Tue, Jan 08, 2019 at 08:17:42PM +, Simon McVittie wrote:
> Package: openssl
> Version: 1.1.1a-1
> Severity: important
> Control: found -1 1.1.1~~pre3-1
> Control: affects -1 steam
>
> The openssl.cnf in the openssl package since 1.1.1~~pre3-1 is incompatible
> with libssl < 1.1.0 (I think
801 - 900 of 14770 matches
Mail list logo
