Re: new OpenSSL flaws
On Sat, 7 Jun 2014 14:19:33 +0400 Solar Designer so...@openwall.com wrote: On Sat, Jun 07, 2014 at 09:13:36AM +0200, Francois Ambrosini wrote: On Sat, 7 Jun 2014 07:04:47 +0400 Solar Designer so...@openwall.com wrote: Being on the distros list is not mandatory to receive advance notification of security issues. The list is just a tool. People reporting security issues to the distros list are encouraged to also notify upstream projects/developers of the affected software, other affected distro vendors, and/or affected Open Source projects. You and others may want to know that ??? since yesterday ??? the OpenSSL wiki says otherwise. Quoting: If you would like advanced notice of vulnerabilities before they are released to the general public, then please join [http://oss-security.openwall.org/wiki/mailing-lists/distros Operating system distribution security contact lists] at OpenWall's OSS Security http://wiki.openssl.org/index.php?title=Security_Advisoriesdiff=1700oldid=1697 Thanks for letting me know. I wasn't aware of this. I don't know whether this wiki edit is authoritative for the OpenSSL project, but if it is it means that there's greater assurance those on distros list will continue to receive advance notification, and indeed it's simpler for the OpenSSL project to be able to notify more distro vendors at once. I don't see it as contradictory to what I wrote (quoted above): it doesn't say that those who haven't joined will definitely not be notified. I guess OpenSSL will maintain an additional list of who to notify, besides the distros list. As I said before, I can't speak for the OpenSSL project, though - so these are just guesses. My personal opinion is that if OpenBSD doesn't join the distros list, yet wants LibreSSL to be notified of OpenSSL security issues, OpenSSL should be notifying LibreSSL directly. I think it'd be helpful if LibreSSL nominates specific contact persons for that, along with PGP keys to use, and informs the OpenSSL project of that. (Use of PGP was mandatory in the recent advance notification offered to distros list.) Once that has been done, you'd have (more) reason to complain if you're not notified next time (but I hope you will be). Alexander I am a mere user who happened to spot an inconsistency and wanted to inform all parties. I will not comment on your guesses and opinions with information I do not have. I'll just state that I find your interpretation of the quote from the OpenSSL wiki rather optimistic, and give you the additional hint that a public statement from Mark Cox on Google+ goes against it (check the timeline post). I humbly think it was (and is) not the right time for guesses and I must confess my surprise at your response. I would have thought that, with the new responsibility given to the distro list, you would want to check with the OpenSSL people first.
Re: new OpenSSL flaws
On Sun, Jun 08, 2014 at 10:38:50AM +0200, Francois Ambrosini wrote: I am a mere user who happened to spot an inconsistency and wanted to inform all parties. I appreciate the constructive nature of your messages. I will not comment on your guesses and opinions with information I do not have. I'll just state that I find your interpretation of the quote from the OpenSSL wiki rather optimistic, It's not interpretation of the quote from their wiki. It's what I think they may and should do next time, given the circumstances, and an observation that the specific wording on the wiki technically does not contradict that. and give you the additional hint that a public statement from Mark Cox on Google+ goes against it (check the timeline post). On the contrary, the timeline shows that distros wasn't the only place OpenSSL sent a notification to. It also lists CERT/CC, ops-trust, and selected OpenSSL Foundation contracts. So OpenSSL did have an additional list of who to notify at that time. I think they may have such a list next time as well, and they may include LibreSSL on it. I humbly think it was (and is) not the right time for guesses and I must confess my surprise at your response. I would have thought that, with the new responsibility given to the distro list, you would want to check with the OpenSSL people first. I think I am in a better position to politely put light pressure on OpenSSL by stating my opinion publicly - namely, suggesting that they notify LibreSSL next time - regardless of how exclusive or not their planned use of the distros list might have been. I especially don't want to end up receiving any non-public information on their decision-making on who and how to notify, at which point I'd have to choose between two evils: reveal something they might disclose to me as (implied or stated) confidential or not informing you and the general public of that something if it's relevant to this discussion. As you can see, I've CC'ed this and the message you replied to, to Mark Cox, who managed OpenSSL's recent notification to distros list. I don't expect Mark to comment, but I'd like him to be aware. Mark - I hope you understand and agree with my position on this, as well as my reasoning for not coordinating this with OpenSSL in private first. Alexander
Re: new OpenSSL flaws
On Fri, Jun 06, 2014 at 10:26:48AM +0400, Solar Designer wrote: On Thu, Jun 05, 2014 at 04:38:24PM -0600, Theo de Raadt wrote: Kurt and Solar -- You are the primary contacts for the oss-security email list. Kurt is not. Sorry for going slightly off-topic, since this is not an OpenBSD thing, but I think it's appropriate to post the below in here. I think I need to clarify Kurt's exact role on oss-security and distros, given how suspicious people are and for the sake of transparency, even though I find this otherwise irrelevant to the issue at hand. BTW, I am not CC'ing this to Kurt because we managed to offend him so much that he doesn't want to receive these e-mails anymore. I'll post the main content of this message to oss-security as well, crediting Theo for the indirect reminder that more transparency is needed. On the linux-distros lists, Kurt is one of the members from Red Hat. He has no special privileges there. Kurt happens to be assigning CVE IDs from Red Hat's pool when people (those reporting vulnerabilities externally and/or other list members) ask for those. Kurt used to be assigning CVE IDs from Red Hat's pool on the public oss-security list as well. He was doing this for a long while, and I think is well recognized for that. Now MITRE takes care of this. Kurt currently has co-moderator privileges on oss-security, for the sole purpose of approving obviously on-topic messages from new addresses (not yet pre-approved), especially when I am not around (but usually I am). This minimizes delivery delays. This does not make Kurt a primary contact for the list - it's a rather limited and technical role, and an unpleasant one (since most messages in the moderation queue are spam), that Kurt at some point agreed to help with (but may resign from it anytime). Another current co-moderator on oss-security is Josh Bressers. Both Kurt and Josh are from Red Hat. The set of co-moderators is occasionally changing as people volunteer or resign. I think I should adopt a practice to announce such changes on oss-security itself right away, for the sake of transparency, even though the additional co-moderators (everyone besides me) only approve obvious on-topic messages and don't reject anything, so the responsibility for the list's policies remains mine (and I am the only one to blame). Conspiracy theorists may now say that this is a privilege that provides (a few hours of?) advance notification, and that messages may be deliberately delayed. I've heard such claims about Bugtraq (they might or might not be right). On oss-security, most messages are from pre-approved senders (so they get posted right away, with no ability for a co-moderator to even see them before they're sent to everyone), and the few that get into the moderation queue are approved quickly (from minutes to hours, but not days - whenever I or a co-moderator gets a chance to check our e-mail and confirm that the message is not spam and is on-topic). Such concerns could apply to Bugtraq (and do apply, as we've seen from some public criticism of Bugtraq) and to FD as well. I think they apply to oss-security to a smaller extent, because a lot of people (who post to oss-security) actually know that delays are usually non-existent or, when they do occur, are much smaller than those on Bugtraq (and likely smaller than those on FD as well, but I'd need to actually analyze the data to make sure). (I do think Bugtraq's delays are often unacceptable, regardless of why they occur.) As far as I'm aware, no oss-security posting was ever abusively delayed. There are some rare occasions where a posting is questionable (neither obviously on-topic nor obviously off-topic) and a moderation decision takes time to make - e.g., sometimes I contact the sender to have them clarify why their posting would be appropriate for oss-security. In those cases, as well as even for obviously off-topic messages, the co-moderators do nothing, and I handle these (almost always same day). IIRC, none of these were vulnerability reports in open source software. I do recall some that were vulnerability reports in closed source software (and this needed to be clarified before they got rejected as off-topic). When such misdirected reports happen, we don't make use of the information in the rejected postings (and the sender typically posts to FD or/and Bugtraq). Alexander
Re: Non-functional USB ports on thinkpad x230t/OpenBSD
On 2014-06-01, Christian Weisgerber na...@mips.inka.de wrote: The blue ports do not appear to function under OpenBSD. They do. I just tried a mouse in all three of my X230's USB ports. It worked in all of them. (I use the default BIOS settings, i.e., USB 3.0 mode [Auto].) It is a BIOS issue. I just updated mine from the ancient 1.12 to 2.61, and when I rebooted with the new BIOS, the USB CD drive I had used for the update was gone from OpenBSD's view. It appears the USB 3.0 mode auto setting is now broken and needs to be changed to disabled. -- Christian naddy Weisgerber na...@mips.inka.de
Re: NOINET6 by default
since no consensus could be found yet for a new command line option to
ifconfig, heck, not even about wether it is needed, I propose this for
now.
1) make ifconfig if inet6 eui64 reset the NOINET6 flag
unconditionally, so a link-local will be assigned if there isn't one
yet.
Index: sbin/ifconfig/ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.283
diff -u -p -r1.283 ifconfig.c
--- sbin/ifconfig/ifconfig.c12 May 2014 08:47:37 - 1.283
+++ sbin/ifconfig/ifconfig.c19 May 2014 00:27:07 -
@@ -411,7 +411,7 @@ const structcmd {
{ flowdst,NEXTARG,0, setpflow_receiver },
{ -flowdst, 1,0, unsetpflow_receiver },
{ pflowproto, NEXTARG,0, setpflowproto },
- { -inet6, IFXF_NOINET6, 0, setifxflags } ,
+ { -inet6, IFXF_NOINET6, 0, setifxflags },
{ keepalive, NEXTARG2, 0, NULL, setkeepalive },
{ -keepalive, 1, 0, unsetkeepalive },
{ add,NEXTARG,0, bridge_add },
@@ -1312,6 +1312,7 @@ setia6eui64(const char *cmd, int val)
if (afp-af_af != AF_INET6)
errx(1, %s not allowed for the AF, cmd);
+ setifxflags(inet6, -IFXF_NOINET6);
in6 = (struct in6_addr *)in6_addreq.ifra_addr.sin6_addr;
if (memcmp(in6addr_any.s6_addr[8], in6-s6_addr[8], 8) != 0)
errx(1, interface index is already filled);
2) turn the NOINET6 flag on by default.
As said previously, it will be reset and thus a link-local assigned
transparently if either
-rtsol(d) is run
-an inet6 address is assigned
-ifconfig if inet6 eui64 is run
and thus should be entirely transparent for the vast majority of inet6
users.
Index: sys/net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.289
diff -u -p -r1.289 if.c
--- sys/net/if.c16 May 2014 08:21:54 - 1.289
+++ sys/net/if.c16 May 2014 14:15:24 -
@@ -423,6 +423,9 @@ if_attach(struct ifnet *ifp)
#else
TAILQ_INSERT_TAIL(ifnet, ifp, if_list);
#endif
+#ifdef INET6
+ ifp-if_xflags |= IFXF_NOINET6;
+#endif
m_clinitifp(ifp);
wether we need a less obscure ifconfig command than eui64 can be
discussed after.
oks?
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/
Re: NOINET6 by default
On 8 June 2014 11:14, Henning Brauer lists-openbsdt...@bsws.de wrote:
since no consensus could be found yet for a new command line option to
ifconfig, heck, not even about wether it is needed, I propose this for
now.
1) make ifconfig if inet6 eui64 reset the NOINET6 flag
unconditionally, so a link-local will be assigned if there isn't one
yet.
Index: sbin/ifconfig/ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.283
diff -u -p -r1.283 ifconfig.c
--- sbin/ifconfig/ifconfig.c12 May 2014 08:47:37 - 1.283
+++ sbin/ifconfig/ifconfig.c19 May 2014 00:27:07 -
@@ -411,7 +411,7 @@ const structcmd {
{ flowdst,NEXTARG,0, setpflow_receiver },
{ -flowdst, 1,0, unsetpflow_receiver },
{ pflowproto, NEXTARG,0, setpflowproto },
- { -inet6, IFXF_NOINET6, 0, setifxflags } ,
+ { -inet6, IFXF_NOINET6, 0, setifxflags },
{ keepalive, NEXTARG2, 0, NULL, setkeepalive },
{ -keepalive, 1, 0, unsetkeepalive },
{ add,NEXTARG,0, bridge_add },
@@ -1312,6 +1312,7 @@ setia6eui64(const char *cmd, int val)
if (afp-af_af != AF_INET6)
errx(1, %s not allowed for the AF, cmd);
+ setifxflags(inet6, -IFXF_NOINET6);
in6 = (struct in6_addr *)in6_addreq.ifra_addr.sin6_addr;
if (memcmp(in6addr_any.s6_addr[8], in6-s6_addr[8], 8) != 0)
errx(1, interface index is already filled);
2) turn the NOINET6 flag on by default.
As said previously, it will be reset and thus a link-local assigned
transparently if either
-rtsol(d) is run
-an inet6 address is assigned
-ifconfig if inet6 eui64 is run
and thus should be entirely transparent for the vast majority of inet6
users.
Index: sys/net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.289
diff -u -p -r1.289 if.c
--- sys/net/if.c16 May 2014 08:21:54 - 1.289
+++ sys/net/if.c16 May 2014 14:15:24 -
@@ -423,6 +423,9 @@ if_attach(struct ifnet *ifp)
#else
TAILQ_INSERT_TAIL(ifnet, ifp, if_list);
#endif
+#ifdef INET6
+ ifp-if_xflags |= IFXF_NOINET6;
+#endif
m_clinitifp(ifp);
wether we need a less obscure ifconfig command than eui64 can be
discussed after.
oks?
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully
Managed
Henning Brauer Consulting, http://henningbrauer.com/
Works for me. ok krw@ for what it's worth.
Ken
libressl compilation issues (?)
Hey guys, I downloaded the latest snapshot, and attempted to build from sources. However, i'm getting those errors: /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c: In function 'ssl_fill_hello_random': /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: 'SSL_MODE_SEND_SERVERHELLO_TIME' undeclared (first use in this function) /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: (Each undeclared identifier is reported only once /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: for each function it appears in.) /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:302: error: 'SSL_MODE_SEND_CLIENTHELLO_TIME' undeclared (first use in this function) *** Error 1 in ssl (bsd.lib.mk:40 's23_clnt.o': @cc -O2 -pipe -g -Wall -Werror -DLIBRESSL_INTERNAL -DTERMIOS -DANSI_SOURCE -DOPENSSL_NO_RC...) *** Error 1 in /usr/src/lib/libssl (bsd.subdir.mk:48 'all' Am I the only one ?
Re: libressl compilation issues (?)
On 2014/06/08 11:49, Loganaden Velvindron wrote: Hey guys, I downloaded the latest snapshot, and attempted to build from sources. However, i'm getting those errors: /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c: In function 'ssl_fill_hello_random': /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: 'SSL_MODE_SEND_SERVERHELLO_TIME' undeclared (first use in this function) /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: (Each undeclared identifier is reported only once /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: for each function it appears in.) /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:302: error: 'SSL_MODE_SEND_CLIENTHELLO_TIME' undeclared (first use in this function) *** Error 1 in ssl (bsd.lib.mk:40 's23_clnt.o': @cc -O2 -pipe -g -Wall -Werror -DLIBRESSL_INTERNAL -DTERMIOS -DANSI_SOURCE -DOPENSSL_NO_RC...) *** Error 1 in /usr/src/lib/libssl (bsd.subdir.mk:48 'all' Am I the only one ? The snapshot is built from newer code than is currently available on anoncvs; syncing out has a few issues still at this time.
Re: libressl compilation issues (?)
On 2014/06/08 20:58, Stuart Henderson wrote: On 2014/06/08 11:49, Loganaden Velvindron wrote: Hey guys, I downloaded the latest snapshot, and attempted to build from sources. However, i'm getting those errors: /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c: In function 'ssl_fill_hello_random': /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: 'SSL_MODE_SEND_SERVERHELLO_TIME' undeclared (first use in this function) /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: (Each undeclared identifier is reported only once /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: for each function it appears in.) /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:302: error: 'SSL_MODE_SEND_CLIENTHELLO_TIME' undeclared (first use in this function) *** Error 1 in ssl (bsd.lib.mk:40 's23_clnt.o': @cc -O2 -pipe -g -Wall -Werror -DLIBRESSL_INTERNAL -DTERMIOS -DANSI_SOURCE -DOPENSSL_NO_RC...) *** Error 1 in /usr/src/lib/libssl (bsd.subdir.mk:48 'all' Am I the only one ? The snapshot is built from newer code than is currently available on anoncvs; syncing out has a few issues still at this time. ...and should now be fixed, some mirrors are updated now, others will follow over the next few hours.
fsck_msdos: out of boundary access
Hi,
Google's Android team uses a modified fsck_msdos version from FreeBSD,
fixing issues in their local repositories. No license adjustments, so we
are free to merge them into ours.
One of these fixes covers an out of boundary access that can occur if
filesystem points to a cluster outside of allocated memory. Their use
case covers h which is a magic number in specification.
In either way, we shouldn't trust a value of a filesystem we are going
to check, so test index value for valid range before using it.
Android commit id 59ae828834dc177c74775cf36cafda4da9927bd9:
https://android.googlesource.com/platform/external/fsck_msdos/+/59ae828834dc177c74775cf36cafda4da9927bd9
This diff is less intrusive, just adding the additional check:
Does somebody agree that this is a good thing to do?
Index: fat.c
===
RCS file: /cvs/src/sbin/fsck_msdos/fat.c,v
retrieving revision 1.18
diff -u -p -r1.18 fat.c
--- fat.c 27 Oct 2009 23:59:33 - 1.18
+++ fat.c 8 Jun 2014 23:30:51 -
@@ -535,7 +535,8 @@ checklost(int dosfs, struct bootblock *b
ret = 1;
}
}
- if (boot-NumFree fat[boot-FSNext].next != CLUST_FREE) {
+ if (boot-NumFree (boot-FSNext = boot-NumClusters ||
+ fat[boot-FSNext].next != CLUST_FREE)) {
pwarn(Next free cluster in FSInfo block (%u) not
free\n,
boot-FSNext);
if (ask(1, fix))
Re: libressl compilation issues (?)
Yeah. Sorry folks I screwed this up on the fanout machine while starting and stopping daemons and cron jobs chasing the cvsync commitid issue. My bad. On 8 Jun 2014 14:20, Stuart Henderson st...@openbsd.org wrote: On 2014/06/08 20:58, Stuart Henderson wrote: On 2014/06/08 11:49, Loganaden Velvindron wrote: Hey guys, I downloaded the latest snapshot, and attempted to build from sources. However, i'm getting those errors: /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c: In function 'ssl_fill_hello_random': /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: 'SSL_MODE_SEND_SERVERHELLO_TIME' undeclared (first use in this function) /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: (Each undeclared identifier is reported only once /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: for each function it appears in.) /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:302: error: 'SSL_MODE_SEND_CLIENTHELLO_TIME' undeclared (first use in this function) *** Error 1 in ssl (bsd.lib.mk:40 's23_clnt.o': @cc -O2 -pipe -g -Wall -Werror -DLIBRESSL_INTERNAL -DTERMIOS -DANSI_SOURCE -DOPENSSL_NO_RC...) *** Error 1 in /usr/src/lib/libssl (bsd.subdir.mk:48 'all' Am I the only one ? The snapshot is built from newer code than is currently available on anoncvs; syncing out has a few issues still at this time. ...and should now be fixed, some mirrors are updated now, others will follow over the next few hours.
Re: Typo in macro name for ASN
On Fri, Jun 06, 2014 at 09:47:03AM +0200, Miod Vallat wrote:
From Quanah Gibson-Mount:
UNKOWN-UNKNOWN
Index: crypto/asn1/asn1_err.c
Please refrain from sending diffs you obviously didn't test.
Miod
Compiled and tested:
Index: src/crypto/asn1/asn1.h
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/asn1.h,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 asn1.h
--- src/crypto/asn1/asn1.h 29 May 2014 20:21:22 - 1.27
+++ src/crypto/asn1/asn1.h 8 Jun 2014 19:40:00 -
@@ -1338,7 +1338,7 @@ void ERR_load_ASN1_strings(void);
#define ASN1_R_UNKNOWN_PUBLIC_KEY_TYPE 163
#define ASN1_R_UNKNOWN_SIGNATURE_ALGORITHM 199
#define ASN1_R_UNKNOWN_TAG 194
-#define ASN1_R_UNKOWN_FORMAT195
+#define ASN1_R_UNKNOWN_FORMAT 195
#define ASN1_R_UNSUPPORTED_ANY_DEFINED_BY_TYPE 164
#define ASN1_R_UNSUPPORTED_CIPHER 165
#define ASN1_R_UNSUPPORTED_ENCRYPTION_ALGORITHM 166
Index: src/crypto/asn1/asn1_gen.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/asn1_gen.c,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 asn1_gen.c
--- src/crypto/asn1/asn1_gen.c 30 May 2014 06:22:57 - 1.9
+++ src/crypto/asn1/asn1_gen.c 8 Jun 2014 19:40:00 -
@@ -355,7 +355,7 @@ asn1_cb(const char *elem, int len, void
else if (!strncmp(vstart, BITLIST, 7))
arg-format = ASN1_GEN_FORMAT_BITLIST;
else {
- ASN1err(ASN1_F_ASN1_CB, ASN1_R_UNKOWN_FORMAT);
+ ASN1err(ASN1_F_ASN1_CB, ASN1_R_UNKNOWN_FORMAT);
return -1;
}
break;
Index: src/crypto/asn1/asn1_err.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/asn1_err.c,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 asn1_err.c
--- src/crypto/asn1/asn1_err.c 19 Apr 2014 10:54:26 - 1.16
+++ src/crypto/asn1/asn1_err.c 8 Jun 2014 19:40:01 -
@@ -303,7 +303,7 @@ static ERR_STRING_DATA ASN1_str_reasons[
{ERR_REASON(ASN1_R_UNKNOWN_PUBLIC_KEY_TYPE), unknown public key type},
{ERR_REASON(ASN1_R_UNKNOWN_SIGNATURE_ALGORITHM), unknown signature
algorithm},
{ERR_REASON(ASN1_R_UNKNOWN_TAG) , unknown tag},
- {ERR_REASON(ASN1_R_UNKOWN_FORMAT), unknown format},
+ {ERR_REASON(ASN1_R_UNKNOWN_FORMAT), unknown format},
{ERR_REASON(ASN1_R_UNSUPPORTED_ANY_DEFINED_BY_TYPE), unsupported any
defined by type},
{ERR_REASON(ASN1_R_UNSUPPORTED_CIPHER) , unsupported cipher},
{ERR_REASON(ASN1_R_UNSUPPORTED_ENCRYPTION_ALGORITHM), unsupported
encryption algorithm},
