This patch against the stable branch makes my AnyConnect VPN client
( http://git.infradead.org/users/dwmw2/anyconnect.git ) work.
Cisco's VPN client uses OpenSSL, and a version of the DTLS protocol
which is newer than we had in 0.9.8e, but older than the final version
defined in the RFC and
This simple fix to the 0.9.8 branch addresses RT #1703, where a DTLS bug
causes applications to abort. It was causing my VPN client to abort
during temporary network problems which it should have coped with and
recovered from.
When the underlying BIO_write() fails to send a datagram, we leave the
This patch to the 0.9.8 branch fixes two bugs with misordered incoming
packets in DTLS, which are reported as RT #1752.
Firstly, the bitmap we use for replay protection was ending up with zero
length, so a _single_ pair of packets getting switched around would
cause one of them to be 'dropped'.
This patch against the 0.9.8 branch adds an SSL option for compatibility
with the pre-RFC version of DTLS used by Cisco for their AnyConnect SSL
VPN. This is RT #1751.
With this patch, and with the two bug fixes I just posted, I now have a
fully functional client operating with Cisco's VPN
On Mon, 2008-10-06 at 13:39 +0200, Lutz Jaenicke wrote:
David Woodhouse via RT wrote:
(Was waiting for the RT to autoreply with a number before I followed up,
but it doesn't seem to have arrived after half an hour, so I'll send
anyway. Hopefully the References: header will associate
On Fri, 2008-10-10 at 12:51 +0200, Lutz Jaenicke via RT wrote:
Could you comment on the 0.9.9-dev branch as well?
The patch to d1_pkt.c applies fine. The length object is gone from the
code so it should not be needed any longer.
Yeah, it looks right. I haven't yet got it working with my test
On Mon, 2008-10-13 at 09:01 +0200, Lutz Jaenicke via RT wrote:
Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling
is not present in HEAD (0.9.9).
That makes sense.
I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the
pre-RFC version of DTLS was considered
On Mon, 2008-10-13 at 13:08 -0700, Pirasenna Velandai Thiyagarajan
wrote:
How to load a DSO from within an engine?
See the code that this patch is mostly ripping out in favour of direct
linking:
http://git.infradead.org/users/dwmw2/openssl-tpm-engine.git?a=commitdiff;h=624a38a1
--
David
, was that
the engine _was_ using DSO_load() and I didn't want it to. The opposite
of the original poster's problem :)
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
Apologies for delayed response. There was some bureaucracy to go through
to make sure I had management approval for releasing the code which
explains my interest in the subject.
That's done now; we have a full open source client for the VPN in
question, and OpenSSL client support for BAD_DTLS_VER
On Sat, 2008-12-20 at 14:00 +0100, David Woodhouse via RT wrote:
On Tue, 2008-10-07 at 10:12 +0100, David Woodhouse wrote:
This patch against the 0.9.8 branch adds an SSL option for compatibility
with the pre-RFC version of DTLS used by Cisco for their AnyConnect SSL
VPN. This is RT #1751
On Sun, 2009-01-11 at 10:47 +, David Woodhouse wrote:
On Sat, 2008-12-20 at 14:00 +0100, David Woodhouse via RT wrote:
On Tue, 2008-10-07 at 10:12 +0100, David Woodhouse wrote:
This patch against the 0.9.8 branch adds an SSL option for compatibility
with the pre-RFC version of DTLS
On Mon, 2009-02-09 at 07:14 +, David Woodhouse wrote:
On Sun, 2009-01-11 at 10:47 +, David Woodhouse wrote:
On Sat, 2008-12-20 at 14:00 +0100, David Woodhouse via RT wrote:
On Tue, 2008-10-07 at 10:12 +0100, David Woodhouse wrote:
This patch against the 0.9.8 branch adds an SSL
On Wed, 2009-02-25 at 16:38 +0100, Ben Laurie via RT wrote:
[dw...@infradead.org - Sat Dec 20 14:00:34 2008]:
On Tue, 2008-10-07 at 10:12 +0100, David Woodhouse wrote:
This patch against the 0.9.8 branch adds an SSL option for compatibility
with the pre-RFC version of DTLS used
On Thu, 2009-02-26 at 13:00 +0900, David Woodhouse wrote:
Generating a patch against HEAD will take me a little longer (and be
less directly useful, in the foreseeable future, because distributions
are actually shipping 0.9.8x.)
I'm working on this; I've rediscovered my standalone test case
On Thu, 2009-04-09 at 09:03 +0200, Ger Hobbelt via RT wrote:
+++ ./crypto/x509v3/v3_crld.c 2009-04-07 11:11:06.0 +0200
@@ -152,7 +152,7 @@
sk_X509_NAME_ENTRY_num(rnm) - 1)-set)
{
On Thu, 2009-02-26 at 21:03 +0900, David Woodhouse wrote:
On Thu, 2009-02-26 at 13:00 +0900, David Woodhouse wrote:
Generating a patch against HEAD will take me a little longer (and be
less directly useful, in the foreseeable future, because distributions
are actually shipping 0.9.8x
On Sun, 2009-04-19 at 19:44 +0100, David Woodhouse wrote:
I finally threw away everything I'd done and started again from scratch,
and I have it working against openssl-1.0.0-beta1.
Thanks for applying it to 0.9.8 and 1.0.0 branches. If we apply this
simple fix first, the 1.0.0 version
Moving to openssl-dev now that I think I've found the answers...
On Sun, 2009-05-31 at 10:13 +0100, David Woodhouse wrote:
I found another strange behaviour that I didn't expect -- the _order_ of
the certificates in the cafile seems to be important. My original
scripts which interact
On Tue, 2009-06-02 at 13:40 +0200, Stephen Henson via RT wrote:
I agree the existing logic is badly broken, it's one of those things
that has been almost untouched since SSLeay days.
If however we are going to revise this I'd say we should use
X509_verify_cert to build the chain instead of
On Tue, 2009-06-02 at 15:21 +0200, David Woodhouse via RT wrote:
On Tue, 2009-06-02 at 13:40 +0200, Stephen Henson via RT wrote:
If however we are going to revise this I'd say we should use
X509_verify_cert to build the chain instead of more ad-hoc stuff.
This seems to work... only tested
On Tue, 2009-06-02 at 15:21 +0200, David Woodhouse via RT wrote:
On Tue, 2009-06-02 at 13:40 +0200, Stephen Henson via RT wrote:
If however we are going to revise this I'd say we should use
X509_verify_cert to build the chain instead of more ad-hoc stuff.
This seems to work... only tested
On Tue, 2009-06-02 at 13:40 +0200, Stephen Henson via RT wrote:
[dw...@infradead.org - Sun May 31 22:08:11 2009]:
It's possible for multiple certificates to have the same subject name,
and if that happens then ssl3_output_cert_chain() may select the wrong
one because it just picks a
On Fri, 2009-06-26 at 16:53 +0200, Dr. Stephen Henson wrote:
Sorry for delay in replying doing a shed load of other stuff at present. The
patch looks OK but will make a few minor changes to it, set the cert in
X509_STORE_CTX_init() instead of the structure accedd.
Does it help if I resubmit a
On Mon, 2009-09-28 at 20:33 -0500, William A. Rowe, Jr. wrote:
since Intel's patches are being rapidly committed?
Heh. I wish :)
--
dwmw2
__
OpenSSL Project http://www.openssl.org
Development
Updated patch; if I'd actually tried the 32-bit build without asm
disabled, I'd have realised that the perl scripts for i386 don't cope
with the aesni assembler source. We'd need to backport some changes to
those perl scripts from HEAD too. We'll maybe get to that later, but
64-bit support is more
On Fri, 2009-09-11 at 17:59 +0200, Dr. Stephen Henson wrote:
Under the new versioning scheme letter changes will retain binary
compatibility. They will be bugfix only and no new features will be added.
There wont be a 0.9.9 to avoid confusion with what we used to call 0.9.9
which is now
On Thu, 2010-01-07 at 09:13 +0100, Matthias Meixner via RT wrote:
It looks like OpenSSL stops searching for certificates as soon as it
has found a certificate with matching common name.
Is this behaviour of OpenSSL correct?
I reported this in May and submitted a patch.
On Sun, 2010-01-17 at 18:41 +0100, Andy Polyakov via RT wrote:
Or two milliard, in which case one doesn't even have to switch to
unsigned. Please test http://cvs.openssl.org/chngview?cn=19095. I opted
for limiting loops at 2^31, because extending to 64-bit is problematic,
as it implies
On Mon, 2009-09-14 at 23:13 +0200, David Woodhouse via RT wrote:
I'm a little confused about the way Intel AES-NI is supported in OpenSSL
HEAD.
This is just a feature of new CPUs, like SSE is. Yet SSE support is
directly included in the normal assembly routines for x86, while AES-NI
automatically, but I still don't quite
understand why it should be an engine while SSE support is not. I'd like
to understand the logic.
Should we be moving the SSE optimisations out into their own engine too?
--
David WoodhouseOpen Source Technology Centre
david.woodho
while
SSE support is not. I'd like to understand the logic.
snip
Thank you very much for the explanation. I'd read through the previous
threads from the time it was originally submitted, but had failed to
pick out the important details. It makes a lot more sense to me now.
--
David Woodhouse
into the 'core' AES functions directly, and
doesn't use EVP.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
__
OpenSSL Project
On Thu, 2010-01-21 at 22:52 +1300, David Woodhouse wrote:
On Thu, 2009-12-17 at 15:29 +, David Woodhouse wrote:
[r...@dwoodhou-mobl2 ~]# openconnect -c vpn.pem --key-password=$PIN
$VPNSERVER --script /etc/vpnc/vpnc-script --mtu 1266
Attempting to connect to $VPNSERVER
SSL
This makes the errors slightly more enlightening...
diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index 41769fe..b2b8d31 100644
--- a/ssl/s3_clnt.c
+++ b/ssl/s3_clnt.c
@@ -2688,7 +2688,7 @@ int ssl3_send_client_verify(SSL *s)
}
else
{
-
On Thu, 2010-04-08 at 18:15 +0100, David Woodhouse wrote:
In the TPM engine case, EVP_PKEY_CTX_new() is returning NULL because
!pkey-ameth.
Was the engine supposed to call EVP_PKEY_assign_RSA() in its load_key
method? This seems to fix it...
--- e_tpm.c 7 Dec 2007 21:55:57 -
On Wed, 2010-05-26 at 21:32 +0200, Ger Hobbelt wrote:
Those [i_a] bits are my markers in our local code base so I know which edits
are mine when doing a (manual) merge with 'vanilla' CVS HEAD. Yes, I know
there are smarter systems around, but I've been 'tracking' OpenSSL for
almost a decade
On Thu, 2010-05-27 at 17:51 +0200, Lutz Jaenicke wrote:
David Woodhouse wrote:
On Wed, 2010-05-26 at 21:32 +0200, Ger Hobbelt wrote:
Those [i_a] bits are my markers in our local code base so I know which
edits
are mine when doing a (manual) merge with 'vanilla' CVS HEAD. Yes, I know
On Fri, 2010-05-28 at 10:14 +0200, Lutz Jaenicke wrote:
The state of the test-repository is a bit old (approx one year) but
you
may have a look into
git://login.openssl.org/openssl
http://www.openssl.org/gitweb.cgi/
When the initial test migrations were performed (2 years ago) I used
On Thu, 2010-06-03 at 18:04 +0200, Dr. Stephen Henson wrote:
If you mean private key security then this makes more sense.
OpenSSL includes means to secure private keys through the ENGINE interface.
There are some built in which can use external private keys (e.g. Windows CSPs
or Chil HSMs).
/Display.html?id=2065user=guestpass=guest
For HEAD:
http://rt.openssl.org/Ticket/Display.html?id=2045user=guestpass=guest
If you could also sacrifice a goat or something in the hope that some of
these patches will eventually make it into OpenSSL, that would also be
appreciated.
--
David Woodhouse
/Display.html?id=2045user=guestpass=guest ?
The patch in Debian almost certainly includes that (since without it,
the whole thing is pointless and the algorithms never get used).
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
case.
You shouldn't need to explicitly reconfigure all applications just to
make a library use a core CPU feature like SSE or AESNI. The library
should get that right for itself.
OpenSSL *does* get that right for SSE, but not (yet) for AESNI.
Hence RT#2045.
--
David Woodhouse
On Thu, 2010-10-07 at 15:09 +0530, Ranjith Kumar A. wrote:
For my testing, i need a source code to send DTLS alerts over SSL to
CISCO router.
Please help me in this, or give some pointers to get this.
In the openconnect VPN client there is an example of connecting to a
Cisco router with
On Mon, 2012-07-09 at 10:49 +0200, Robin Seggelmann wrote:
Is Cisco still using the wrong version or did they fix that?
Cisco are still using the wrong version.
For a while when I first started looking at this (in 2008), they
actually did *accept* a connection with DTLS v1.0. The handshake
On Thu, 2012-06-28 at 07:45 +, Ghennadi Procopciuc wrote:
We observed that the current implementation contains a client that can
communicate with a DTLS1_BAD_VER server but does not contains the server that
can communicate with a DTLS1_BAD_VER client, so we wrote a patch that enables
I have encountered a server which presents an invalid set of
certificates in its TLS handshake.
It's presenting four certificates, where the second cert is *not* the
issuer of the first cert in the list. The chain from #2-#3-#4 is fine,
but #2 isn't actually the issuer of #1. (It just happens to
On Thu, 2012-07-12 at 20:44 +0200, Erwann Abalea wrote:
Le 12/07/2012 15:36, David Woodhouse a écrit :
I have encountered a server which presents an invalid set of
certificates in its TLS handshake.
This is common. Really common.
It's presenting four certificates, where the second cert
On Mon, 2013-02-11 at 20:59 +, David Woodhouse wrote:
From 32cc2479b473c49ce869e57fded7e9a77b695c0d Mon Sep 17 00:00:00 2001
From: Dr. Stephen Henson st...@openssl.org
Date: Thu, 7 Feb 2013 21:06:37 +
Subject: [PATCH] Fix IV check and padding removal.
...
+ if (s-version
From 32cc2479b473c49ce869e57fded7e9a77b695c0d Mon Sep 17 00:00:00 2001
From: Dr. Stephen Henson st...@openssl.org
Date: Thu, 7 Feb 2013 21:06:37 +
Subject: [PATCH] Fix IV check and padding removal.
...
+ if (s-version = TLS1_1_VERSION || s-version == DTLS1_VERSION)
That's
On Mon, 2013-02-11 at 13:24 -0800, Ben Laurie wrote:
Ah, it looks like you only moved the offending code; it was actually
Ben's fault in commit 9f27de17 / 014265eb.
Gah! I wish tests would pick up stuff like this!
As far as I'm aware there are no tests for DTLS1_BAD_VER. Apart from my
Same fix for 1.0.0 branch:
diff --git a/ssl/s3_cbc.c b/ssl/s3_cbc.c
index 5b3f371..61413b8 100644
--- a/ssl/s3_cbc.c
+++ b/ssl/s3_cbc.c
@@ -148,7 +148,7 @@ int tls1_cbc_remove_padding(const SSL* s,
unsigned padding_length, good, to_check, i;
const unsigned overhead = 1 /* padding
be careful not to give the impression that DTLS
will magically give you an in-order, guaranteed-delivery data stream.
It won't; it's still a datagram protocol at heart.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
On Thu, 2013-03-07 at 19:54 +0100, Kurt Roeckx via RT wrote:
On Thu, Mar 07, 2013 at 12:41:43PM +0100, Tomas Mraz via RT wrote:
On Fri, 2013-03-01 at 22:01 +0100, Kurt Roeckx wrote:
I can't either, and yet I have multiple people reporting problems
with the 1.0.1e version saying the
On Fri, 2013-03-15 at 17:17 +0100, Lutz Jaenicke wrote:
The new server currently hosting the www, git, rt, ftp, and cvs
services is going to be moved within the installation of our hoster.
As a consequence, the system will be assigned a new IP address.
Old: 178.16.220.54
New:
://wiki.openssl.org/index.php/1.1_API_Changes#Things_that_Broke_in_OpenConnect
I can either update my code to create the ASN.1 for itself and use
d2i_SSL_SESSION() relying on the patch above, or I can implement the
'alternative' new function if that's preferred.
--
David Woodhouse
On Tue, 2015-02-17 at 22:48 +0100, David Woodhouse via RT wrote:
Commit 9cf0f187 in HEAD, and 68039af3 in 1.0.2, removed a version check
from dtls1_buffer_message() which was needed to distinguish between DTLS
1.x and Cisco's pre-standard version of DTLS.
Further testing shows that simply
on what version of the ASA
code you are running.
I still haven't seen any version of the ASA using anything but
DTLS1_BAD_VER so far.
We do use DTLS1.2 and AES-GCM with ocserv, but not the Cisco ASA.
--
David WoodhouseOpen Source Technology Centre
david.woodho
an error instead?
This is just a sanity check on our own output; it doesn't see incoming
packets.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
(Dropping rt@ from Cc as it doesn't seem to be working any more).
On Mon, 2015-02-16 at 10:28 +, David Woodhouse wrote:
Connected vpntest0 as 192.168.1.13, using SSL
d1_both.c(1112): OpenSSL internal error, assertion failed:
s-d1-w_msg_hdr.msg_len + DTLS1_CCS_HEADER_LENGTH == (unsigned
the patch I sent before... but
then again, DTLS1_BAD_VER in HEAD and 1.0.2 is utterly hosed anyway, so
I'm not going to lose much sleep over that for now.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel
to make this
work again. Should I do the minimal fix to make d2i_SSL_SESSION() work
for DTLS1_BAD_VER, or introduce a new API for setting the fields we need
to fake a session resume?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
I played with manually creating the ASN.1 representation of a session
and feeding it to d2i_SSL_SESSION() but that fails because ssl_version
is 0x100 (DTLS1_BAD_VER) and d2i_SSL_SESSION() only works if the SSL
version major is = SSL3_VERSION_MAJOR.
That sounds like a bug. I can't think of a
On Mon, Feb 16, 2015 at 02:16:15PM -, David Woodhouse wrote:
What fields do you need access to?
Basically just SSL version, cipher, master secret and session ID. Enough
to fake resuming a session that never really existed.
Does the constructed DTLS session re-use the parameters
Commit 9cf0f187 in HEAD, and 68039af3 in 1.0.2, removed a version check
from dtls1_buffer_message() which was needed to distinguish between DTLS
1.x and Cisco's pre-standard version of DTLS.
$DEITY knows why Cisco haven't moved to the standard version of DTLS by
now. The RFC was published in
On Mon, 2015-03-09 at 12:11 +0100, Matt Caswell via RT wrote:
Fixed in this commit:
https://github.com/openssl/openssl/commit/f7683aaf36341dc65672ac2ccdbfd4a232e3626d
Thanks. I can confirm that OpenConnect is now working with OpenSSL HEAD
again, both with DTLS1_BAD_VER talking to 'legacy'
On Tue, 2015-03-17 at 22:22 +, Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
wrote:
Thank you for your responses, PKCS#11 could be the right way to go. I
am hoping there is flexibility as per what functionality I want to
delegate (just need the decrypt piece).
If I had to implement a fully fledged
On Tue, 2015-03-17 at 15:44 +, Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
wrote:
Recently I had to work on an openssl project where due to security
requirements I had to place the private key for the server certificate
on another machine. In order to be able to make openssl ignore the
fake
On Tue, 2015-03-03 at 12:00 +, Matt Caswell wrote:
On 03/03/15 11:36, David Woodhouse wrote:
On Tue, 2015-03-03 at 08:58 +, Matt Caswell wrote:
Fixes for #3703 and #3711 are currently going through the review
process so should be in soon hopefully.
Any progress
On Tue, 2015-03-03 at 16:03 +0100, Nikos Mavrogiannopoulos wrote:
I don't know whether you'd like to depend on gnutls for testing, but I
have a test of most ciphersuites [0] in common under various protocols
between openssl and gnutls. That currently doesn't cope with DTLS0.9
(gnutls' name
On Tue, 2015-03-03 at 14:43 +, Matt Caswell wrote:
On 03/03/15 14:28, David Woodhouse wrote:
On Tue, 2015-03-03 at 12:00 +, Matt Caswell wrote:
I'll look at adding test cases to exercise the DTLS_BAD_VER support,
to
try to avoid this kind of thing happening in future
On Tue, 2015-03-03 at 12:00 +, Matt Caswell wrote:
I'll look at adding test cases to exercise the DTLS_BAD_VER support,
to
try to avoid this kind of thing happening in future.
That would be fantastic to have.
I look a quick look at this. Adding DTLSv1 and DTLSv1.2 support to
On Mon, 2015-02-23 at 14:34 +, David Woodhouse wrote:
I have created pull requests on Github for HEAD and 1.0.2:
https://github.com/openssl/openssl/pull/228 (master)
https://github.com/openssl/openssl/pull/229 (OpenSSL_1_0_2-stable)
These contain the fixes I have already filed in RT#3703
On Tue, 2015-03-03 at 08:58 +, Matt Caswell wrote:
Fixes for #3703 and #3711 are currently going through the review
process so should be in soon hopefully.
Thanks. Should I have known that? I've been monitoring RT (when it's up)
and the mailing list, but is there somewhere else I should
DTLSv0_9_client_method() as discussed¹ in
RT#3711. I didn't do that for 1.0.2 but perhaps we could.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
¹ OK, 'discussed' is a strong word...
smime.p7s
.
It's worth filing a new GCC bug even if there's a possibility that it
might turn out to be a duplicate.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME
On Sat, 2015-05-02 at 16:19 +0200, Rich Salz via RT wrote:
After ten years, the answer is no we are not supporting this now.
We really ought to fix PKCS#11 support though, to make it a first
class citizen.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
On Fri, 2015-05-15 at 17:17 +0530, Animesh Das wrote:
I have a new hardware crypto engine. The device can be accessed
from user space application opening the device like
/dev/mydevice. There are also some IOCTLs which can be used from
user space. I want to add that device as one of the
On Thu, 2015-06-25 at 15:45 +, Viktor Dukhovni wrote:
On Thu, Jun 25, 2015 at 04:34:34PM +0100, Matt Caswell wrote:
Whether such a patch would be accepted though is an entirely
different
thing. Personally I would prefer new engines to be maintained
outside of
the OpenSSL tree.
On Wed, 2015-07-22 at 16:47 +, Viktor Dukhovni wrote:
On Wed, Jul 22, 2015 at 03:36:40PM +, David Woodhouse via RT
wrote:
FWIW the Linux kernel also specifically avoids checking timestamps
altogether when validating signed modules.
You probably need a dedicated implementation
at the store
error status at all; we only care about the return value from
X509_verify_cert() — either directly, or when PKCS7_verify() calls it.
(There's no SSL here; only crypto. It's for verifying certificate
chains and checking signatures on boot images).
So I think it's fine.
--
David
= david.woodho...@intel.com
error 10 at 0 depth lookup:certificate has expired
/home/dwmw2/.cert.20100813/certificate.pem: OK
[dwoodhou@i7 apps]$ ./openssl verify -no_check_time
~/.cert.20100813/certificate.pem
/home/dwmw2/.cert.20100813/certificate.pem: OK
--
David Woodhouse
to the standard
open source UEFI offering.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev
and reduce the need for that. I might do that later, but in the
meantime let's at least not make the problem *worse* with my original
placement of OPENSSL_SYS_UEFI in e_os.h.
Also tidy up the definition of the standard integer types to make it
work cleanly in the MSVC build.
--
David Woodhouse
On Fri, 2015-08-07 at 15:07 +, Blumenthal, Uri - 0553 - MITLL
wrote:
Considering emerging attacks against UEFI I'd be hesitant weakening
protection mechanisms, even those that *currently* aren't likely to
be used.
Can you suggest a practicable means by which this *could* be used?
--
assembly in OpenSSL. And because we actively do not care
about losing those pieces of functionality.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic
On Fri, 2015-08-07 at 15:34 +, Blumenthal, Uri - 0553 - MITLL via
RT wrote:
Alas, not right now (and here we're in agreement).
However I expect the field to evolve with the threats, and the means
for using this capability to emerge.
UEFI is widely mocked for how bloated it is, given
On Thu, 2015-08-06 at 02:36 +0100, Jonathan Larmour wrote:
A CLA is a way of getting the employee to consider and affirm that they do in
fact own the copyright to a contribution. Alternatively, the employer can do
the CLA.
Many projects have started using 'Signed-off-by' to indicate this,
, please?
If I can move them towards fixes which are at least *destined* for
upstream, that would be a step in the right direction...
Thanks.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
On Wed, 2015-07-22 at 16:13 +, Salz, Rich wrote:
I'm willing to forward them to you, and if you want to review and
rebase, etc., that would make it quicker.
Please.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
fixes the OPENSSL_NO_CMS build yet? :)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
¹ http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/b599f07d
smime.p7s
Description: S/MIME
/* !OPENSSL_NO_STDIO */
/* Add a certificate to a BUF_MEM structure */
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
¹ http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/eb73a6112
smime.p7s
altogether when validating signed modules.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
than picking up the filename and
line on which OPENSSL_FILE and OPENSSL_LINE respectively were defined?
Perhaps it could be just depend on OPENSSL_SMALL_FOOTPRINT?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
2001
From: David Woodhouse david.woodho...@intel.com
Date: Thu, 23 Jul 2015 17:30:06 +0100
Subject: [PATCH] Revert OPENSSL_NO_xxx cleanup: RFC3779
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This reverts the non-cleanup parts of commit c73ad69017. We
On Thu, 2015-07-23 at 20:33 +, Salz, Rich via RT wrote:
How about 256 on the stack?
Sure.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
From 57aa658b429b1962e2811c30e2b77edb85d134d3 Mon
-- */
+# if defined(OPENSSL_SYS_UEFI)
+# undef OPENSSL_SYS_UNIX
+# endif
+
/* - Microsoft operating systems -- */
/*
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
On Wed, 2015-07-22 at 22:42 +0200, Kurt Roeckx wrote:
On Wed, Jul 22, 2015 at 03:36:40PM +, David Woodhouse via RT
wrote:
FWIW the Linux kernel also specifically avoids checking timestamps
altogether when validating signed modules.
What do you mean wit timestamps? The trusted
On Wed, 2015-07-22 at 22:40 +0200, Kurt Roeckx wrote:
On Wed, Jul 22, 2015 at 04:36:27PM +0100, David Woodhouse wrote:
On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote:
The way this is supposed to work is by using a timestamp from a
trusted timestamp server to show the certificate
On Wed, 2015-07-22 at 23:29 +0200, Kurt Roeckx wrote:
On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse wrote:
The more I look at this 'signed timestamp' scheme, the more pointless
it seems in this situation. We basically don't *care* about the wall
-clock time, *and* we don't
1 - 100 of 282 matches
Mail list logo
