From nicolas@REDACTED Wed Sep 1 14:05:23 2010 From: nicolas@REDACTED (Nicolas Niclausse) Date: Wed, 01 Sep 2010 14:05:23 +0200 Subject: [erlang-bugs] ssl handshake failure on R14A (and git) In-Reply-To: <4C7BBD46.8050501@erix.ericsson.se> References: <4C738B44.4050808@niclux.org> <4C7BBD46.8050501@erix.ericsson.se> Message-ID: <4C7E4183.9080804@niclux.org> Ingela Anderton Andin ecrivait le 30/08/2010 16:16: > Hi! > > We have located this bug and fixed it, it has to do with the fact that > your server sends > several handshake protocol messages in the same TLS record protocol > message, which is fine > and allowed but not all servers do. We had to move some of our code > hinger up in our model to properly > handle this. We will push this to the public repository soon but due to > some failing test cases it may be a couple > of days. OK, i'm waiting for the update then. Thanks! -- Nicolas From kruber@REDACTED Thu Sep 2 09:57:32 2010 From: kruber@REDACTED (Nico Kruber) Date: Thu, 2 Sep 2010 09:57:32 +0200 Subject: [erlang-bugs] nocatch error in dialyzer, R14A In-Reply-To: <4C7D0AFC.5040804@cs.ntua.gr> References: <201008311459.09585.kruber@zib.de> <201008311502.10956.kruber@zib.de> <4C7D0AFC.5040804@cs.ntua.gr> Message-ID: <201009020957.33284.kruber@zib.de> On Tuesday 31 August 2010 16:00:28 Kostis Sagonas wrote: > Nico Kruber wrote: > > On Tuesday 31 August 2010 14:59:02 Nico Kruber wrote: > >> While I was trying to make a minimal example for another strange > >> behaviour of the dialyzer I found the following bug calling > >> > >>> dialyzer -Werror_handling -Wrace_conditions --src -c rec*.erl > >>> --no_native > >> > >> with the attached files in the current directory: > >> Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes > >> Proceeding with analysis... > >> > >> =ERROR REPORT==== 31-Aug-2010::14:53:04 === > >> Error in process <0.29.0> with exit value: {{nocatch,{error, > >> [73,108,108,101,103,97,108,32,100,101,99,108,97,114,97,116,105,111,110,3 > >> 2,1 11,102,32,"rec2",35,123,"id",125,10]}}, > >> [{erl_types,record_from_form,5},{erl_types,t_from_form,3},{erl_types,'- > >> t_opaque_from_records/1-anonymous-2-',3},{dict,map_bucket,2}, > >> {dict,map_bkt_list,2},{dict... > >> > >> > >> dialyzer: Analysis failed with error: {{nocatch,{error, > >> [73,108,108,101,103,97|...]}}, > >> > >> [{erl_types,record_from_form,5}, > >> > >> {erl_types,t_from_form,3}, > >> {erl_types,'-t_opaque_from_records/1-anonymous-2-',3}, > >> {dict,map_bucket,2}, > >> {dict,map_bkt_list,2}, > >> {dict,map_bkt_list,2}, > >> {dict,map_seg_list,...}, > >> {dict,...}]} > >> > >> Last messages in the log cache: > >> Reading files and computing callgraph... done in 0.06 secs > >> Removing edges... done in 0.01 secs > >> Typesig analysis for SCC: [{rec2,module_info,1}] > > > > I forgot to mention that if you replace opaque with type in rec2.erl, it > > works > > Same issue here with the other one. Simply change the declaration: > > -record(rec2, {id :: rec1:rec1()}). > -opaque(rec2() :: #rec2{id :: rec1:rec1()}). > > to the equivalent ones: > > -record(rec2, {id :: rec1:rec1()}). > -opaque(rec2() :: #rec2{}). same here: those are not equivalent since -opaque(rec2() :: #rec2{}). will be silently expanded to -opaque(rec2() :: #rec2{id :: 'undefined' | rec1:rec1()}). since there is no initialiser in the record's field definition. The definition I provided yields to the expected behaviour, i.e. without the 'undefined' atom. see http://www.erlang.org/doc/reference_manual/typespec.html#id2272601 Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From daniel.goertzen@REDACTED Thu Sep 2 21:31:38 2010 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Thu, 2 Sep 2010 14:31:38 -0500 Subject: ssh-2.0 "Key exchange failed" if known_hosts cannot be written Message-ID: While trying to use ssh:connect(), I get {error, "Key exchange failed"}. Tracing shows that it is trying to write to the file "c:/Users/myname/.ssh/known_hosts". The ".ssh" dir is not present, so the write fails. The error propagates up causing verify_host_key() to return failure which kills the connection. The host key verified properly; it just couldn't be written to known_hosts. I think it should return 'ok' in this case and allow the connection to proceed. My whole connect call was.... {ok,Connection} = ssh:connect(Host, Port, [ {user,Login}, {password,Pass}, {silently_accept_hosts, true}, {user_interaction, false}]), This is for a machine to machine connection, and I don't care about host key checking anyway. To work around this for now, I am supplying a 'user_dir' option so it can write a known_hosts file. Dan. From tuncer.ayaz@REDACTED Thu Sep 2 23:26:48 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 2 Sep 2010 23:26:48 +0200 Subject: [erlang-bugs] ssh-2.0 "Key exchange failed" if known_hosts cannot be written In-Reply-To: References: Message-ID: On Thu, Sep 2, 2010 at 9:31 PM, Daniel Goertzen wrote: > While trying to use ssh:connect(), I get {error, "Key exchange failed"}. > > Tracing shows that it is trying to write to the file > "c:/Users/myname/.ssh/known_hosts". The ".ssh" dir is not present, so the > write fails. The error propagates up causing verify_host_key() to return > failure which kills the connection. The host key verified properly; it just > couldn't be written to known_hosts. I think it should return 'ok' in this > case and allow the connection to proceed. > > My whole connect call was.... > > {ok,Connection} = ssh:connect(Host, Port, [ > {user,Login}, > {password,Pass}, > {silently_accept_hosts, true}, > {user_interaction, false}]), > > This is for a machine to machine connection, and I don't care about host key > checking anyway. To work around this for now, I am supplying a 'user_dir' > option so it can write a known_hosts file. I've sent a patch for review to erlang-patches@ which makes sure that ~/.ssh exists before trying to open any files for read/write. From fauli@REDACTED Mon Sep 6 19:26:36 2010 From: fauli@REDACTED (Christian Faulhammer) Date: Mon, 6 Sep 2010 19:26:36 +0200 Subject: Build system ignores custom LDFLAGS Message-ID: <20100906192636.27593a47@gentoo.org> Hi, as a follow-up to the thread starting in http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1249, I would like to report an issue with the megaco_flex Makefile in 14A, ignoring custom LDFLAGS. A patch has been reported in above thread, where this exact issue got already fixed, but only partly taken over. Please apply the attached patch to the release branch. This has been reported in http://bugs.gentoo.org/show_bug.cgi?id=335964 V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-the-megaco_flex_scanner-respect-custom-LDFLAGS.patch Type: text/x-patch Size: 942 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tuncer.ayaz@REDACTED Wed Sep 8 14:02:59 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 8 Sep 2010 14:02:59 +0200 Subject: beam.smp (enable-native-libs) hang Message-ID: Erlang version: a78b39a0e9ff2cfd13273ab077dc852d70565647 Build Options: --enable-native-libs (HiPE is enabled automatically) Arch: linux 2.6.35 x86_32, glibc 2.12.1 darwin 10.6.4 x86_64 Symptom: beam.smp hangs/doesn't terminate Steps to reproduce: There are two known ways to reproduce the issue and the simplest is: $ hg clone http://bitbucket.org/basho/rebar $ cd rebar $ make [...] Recompile: src/rebar_xref ^Cmake: *** [all] Interrupt Compiling src/rebar_xref.erl hangs indefinitely at 100% cpu load. You can also reproduce the hang running 'rebar compile' in a project that makes use of it. A shared trait is running an escript. From ulf.wiger@REDACTED Fri Sep 10 09:39:09 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 10 Sep 2010 09:39:09 +0200 Subject: timer_server loses its brains (Fwd: Re: [erlang-questions] System limit bringing down rex and the VM) Message-ID: <4C89E09D.7010906@erlang-solutions.com> I thought I'd forward this to the erlang-bugs list as well. The timer_server should make up its mind - if it intends to restart after crashing, it must remember all existing timers. Otherwise, it would be better for it to act as a true kernel process and bring down the node. BR, Ulf W -------- Original Message -------- Subject: Re: [erlang-questions] System limit bringing down rex and the VM Date: Fri, 10 Sep 2010 09:33:27 +0200 From: Ulf Wiger Organization: Erlang Solutions, Ltd. To: erlang-questions@REDACTED On 09/09/2010 07:33 PM, Musumeci, Antonio S wrote: > > I'm seeing mnesia, rex and timer_server in my dump. If you > kill timer_server though it restarts. Actually, I consider this a bug. Let's check to see what the result is of killing timer_server. Eshell V5.7.5 (abort with ^G) 1> F = fun() -> timer:send_after(15000,self(),hello), receive Msg -> io:fwrite("got ~p~n", [Msg]) end end. #Fun 2> f(P), P = spawn(F), time(). {9,25,48} got hello 3> time(). {9,26,6} 4> whereis(timer_server). <0.38.0> 5> f(P), P = spawn(F), time(). {9,26,22} 6> exit(whereis(timer_server),kill). true 7> whereis(timer_server). <0.43.0> 8> time(). {9,27,0} 9> process_info(P). [{current_function,{erl_eval,receive_clauses,6}}, {initial_call,{erlang,apply,2}}, {status,waiting}, {message_queue_len,0}, {messages,[]}, ... So killing timer_server caused it to bounce back, but in the process, it forgot all outstanding requests, so any processes depending on the reliable service of the timer server are now left hanging, with no indication whatsoever that something went wrong. Personally, I think it would be much better if the timer server would in fact stay dead, and bring the whole node down with it - that, or make sure that its dying and restarting is truly transparent. Choosing a middle way of merely pretending to be robust is the worst possible choice. Rather than concluding that the OTP team are incompetent in matters of robustness (as there is overwhelming evidence that they are anything but), I'd like to see this as yet another example of how desperately difficult and dangerous it is to go down the path you're suggesting. It may seem like a respectful thing to do, but you take on a very heavy burden, and may well be much more likely to compound the problem rather than helping it. BR, Ulf W ________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED From vincent.dephily@REDACTED Mon Sep 13 10:37:01 2010 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Mon, 13 Sep 2010 10:37:01 +0200 Subject: [erlang-bugs] illegal declaration of pertially defined record types in dialyzer, R14A In-Reply-To: <201008311603.43854.kruber@zib.de> References: <201008311526.18180.kruber@zib.de> <4C7D0842.7010106@cs.ntua.gr> <201008311603.43854.kruber@zib.de> Message-ID: <201009131037.01152.vincent.dephily@mobile-devices.fr> On Tuesday 31 August 2010 16:03:38 Nico Kruber wrote: > The type I use now is defined opaque but every method in the according > module gets well-formed records, i.e. no 'undefined' fields. I cannot > provide useful initialisers though because we store pids, for example. > We not have to distinguish well-formed records and those that may be > partially undefined and the given declaration would solve this problem. What I do in those cases is to set a throw()n value as the default value. It's not 100% satisfying but it solves a few problems : -define(required(Record, Field), throw({record_field_required, Record, Field, ?MODULE})). -record(file, {size = ?required(file, size) :: integer()}). -- Vincent de Phily From mryufeng@REDACTED Wed Sep 15 04:55:51 2010 From: mryufeng@REDACTED (Feng Yu) Date: Wed, 15 Sep 2010 10:55:51 +0800 Subject: otp --with-libatomic_ops compile hangs Message-ID: Hi all, Erlang version: 9c563c44bb4a7aeabb737ddf4dca5d6639502397 Build Options: --with-libatomic_ops=/usr Arch: Linux yufeng-laptop 2.6.32-25-generic #43-Ubuntu SMP Wed Sep 1 09:46:13 UTC 2010 x86_64 GNU/Linux Libatomic_ops: apt-get -y install libatomic-ops-dev Symptom: beam.smp hangs/doesn't terminate Steps to reproduce: There are two known ways to reproduce the issue and the simplest is: $ git clone git://github.com/erlang/otp.git $ cd otp $ ./otp_build autoconf $ ./configure --with-libatomic_ops=/usr $ make [...] make[4]:?????? `/usr/src/otp/lib/hipe/main' erlc -W +debug_info +inline -o../ebin hipe_rtl.erl make hang here. thanks! From mikpe@REDACTED Wed Sep 15 11:48:32 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 15 Sep 2010 11:48:32 +0200 Subject: [erlang-bugs] otp --with-libatomic_ops compile hangs In-Reply-To: References: Message-ID: <19600.38512.824905.147536@pilspetsen.it.uu.se> Feng Yu wrote: > Build Options: --with-libatomic_ops=/usr > > Arch: > Linux yufeng-laptop 2.6.32-25-generic #43-Ubuntu SMP Wed Sep 1 09:46:13 > UTC 2010 x86_64 GNU/Linux > > Libatomic_ops: > apt-get -y install libatomic-ops-dev > > Symptom: beam.smp hangs/doesn't terminate > > Steps to reproduce: > > There are two known ways to reproduce the issue and the simplest is: > > $ git clone git://github.com/erlang/otp.git > $ cd otp > $ ./otp_build autoconf > $ ./configure --with-libatomic_ops=/usr > $ make > [...] > make[4]:=D5=FD=D4=DA=C0=EB=BF=AA=C4=BF=C2=BC `/usr/src/otp/lib/hipe/main' > erlc -W +debug_info +inline -o../ebin hipe_rtl.erl > > make hang here. Configuring with libatomic_ops seems to be a new option since post-R14A. Since you're on x86_64 Linux you shouldn't need it. Does it work without that option? From rickard@REDACTED Wed Sep 15 16:37:15 2010 From: rickard@REDACTED (Rickard Green) Date: Wed, 15 Sep 2010 16:37:15 +0200 Subject: [erlang-bugs] otp --with-libatomic_ops compile hangs Message-ID: <4C90DA1B.7020900@erlang.org> > Feng Yu wrote: >> Build Options: --with-libatomic_ops=/usr >> >> Arch: >> Linux yufeng-laptop 2.6.32-25-generic #43-Ubuntu SMP Wed Sep 1 09:46:13 >> UTC 2010 x86_64 GNU/Linux >> >> Libatomic_ops: >> apt-get -y install libatomic-ops-dev >> >> Symptom: beam.smp hangs/doesn't terminate >> >> Steps to reproduce: >> >> There are two known ways to reproduce the issue and the simplest is: >> >> $ git clone git://github.com/erlang/otp.git >> $ cd otp >> $ ./otp_build autoconf >> $ ./configure --with-libatomic_ops=/usr >> $ make >> [...] >> make[4]:=D5=FD=D4=DA=C0=EB=BF=AA=C4=BF=C2=BC `/usr/src/otp/lib/hipe/main' >> erlc -W +debug_info +inline -o../ebin hipe_rtl.erl >> >> make hang here. > > Configuring with libatomic_ops seems to be a new option since > post-R14A. Since you're on x86_64 Linux you shouldn't need it. > > Does it work without that option? I was able to reproduce the hang using libatomic_ops-1.2 and libatomic_ops-7.2alpha4 on an Ubuntu 9.10, x86_64, gcc 4.4.1. However, using the atomic implementation part of OTP every things works fine. On SLES 10.1, x86_64, gcc 4.1.2, libatomic_ops-7.2alpha4 worked fine. We have added support for use of libatomic_ops since it makes it possible to utilize optimized native atomic operations on more platforms than before. On x86_64 there is however no need to use libatomic_ops. If configure doesn't complain, there is no need for libatomic_ops. Cut from release the note: The ethread library contains native atomic implementations for, x86 (32 and 64 bit), powerpc (32 bit), sparc V9 (32 and 64 bit), and tilera (32 bit). On other hardware gcc's builtin support for atomic memory access will be used if such exists. If no such support is found, configure will warn about no atomic implementation available. The ethread library can now also use the libatomic_ops library for atomic memory accesses. This makes it possible for the Erlang runtime system to utilize optimized native atomic operations on more platforms than before. If configure warns about no atomic implementation available, try using the libatomic_ops library. Use the --with-libatomic_ops=PATH configure command line argument when specifying where the libatomic_ops installation is located. The libatomic_ops library can be downloaded from: http://www.hpl.hp.com/research/linux/atomic_ops/ It looks like a bug outside of OTP, and we currently don't have the time to look closer into this, but we will do that when time allows us some time in the future. Regards, Rickard Green -- Rickard Green, Erlang/OTP, Ericsson AB. From rickard@REDACTED Wed Sep 15 20:39:20 2010 From: rickard@REDACTED (Rickard Green) Date: Wed, 15 Sep 2010 20:39:20 +0200 Subject: [erlang-bugs] otp --with-libatomic_ops compile hangs In-Reply-To: <4C90DA1B.7020900@erlang.org> References: <4C90DA1B.7020900@erlang.org> Message-ID: <4C9112D8.9050000@erlang.org> Rickard Green wrote: >> Feng Yu wrote: >>> Build Options: --with-libatomic_ops=/usr >>> >>> Arch: >>> Linux yufeng-laptop 2.6.32-25-generic #43-Ubuntu SMP Wed Sep 1 >>> 09:46:13 >>> UTC 2010 x86_64 GNU/Linux >>> >>> Libatomic_ops: >>> apt-get -y install libatomic-ops-dev >>> >>> Symptom: beam.smp hangs/doesn't terminate >>> >>> Steps to reproduce: >>> >>> There are two known ways to reproduce the issue and the simplest is: >>> >>> $ git clone git://github.com/erlang/otp.git >>> $ cd otp >>> $ ./otp_build autoconf >>> $ ./configure --with-libatomic_ops=/usr >>> $ make >>> [...] >>> make[4]:=D5=FD=D4=DA=C0=EB=BF=AA=C4=BF=C2=BC >>> `/usr/src/otp/lib/hipe/main' >>> erlc -W +debug_info +inline -o../ebin hipe_rtl.erl >>> >>> make hang here. >> >> Configuring with libatomic_ops seems to be a new option since >> post-R14A. Since you're on x86_64 Linux you shouldn't need it. >> >> Does it work without that option? > > I was able to reproduce the hang using libatomic_ops-1.2 and > libatomic_ops-7.2alpha4 on an Ubuntu 9.10, x86_64, gcc 4.4.1. However, > using the atomic implementation part of OTP every things works fine. > > On SLES 10.1, x86_64, gcc 4.1.2, libatomic_ops-7.2alpha4 worked fine. > > We have added support for use of libatomic_ops since it makes it > possible to utilize optimized native atomic operations on more platforms > than before. On x86_64 there is however no need to use libatomic_ops. If > configure doesn't complain, there is no need for libatomic_ops. > > Cut from release the note: > The ethread library contains native atomic implementations for, x86 > (32 and 64 bit), powerpc (32 bit), sparc V9 (32 and 64 bit), and > tilera (32 bit). On other hardware gcc's builtin support for atomic > memory access will be used if such exists. If no such support is > found, configure will warn about no atomic implementation available. > > The ethread library can now also use the libatomic_ops library for > atomic memory accesses. This makes it possible for the Erlang runtime > system to utilize optimized native atomic operations on more > platforms than before. If configure warns about no atomic > implementation available, try using the libatomic_ops library. Use > the --with-libatomic_ops=PATH configure command line argument when > specifying where the libatomic_ops installation is located. The > libatomic_ops library can be downloaded from: > http://www.hpl.hp.com/research/linux/atomic_ops/ > > It looks like a bug outside of OTP, and we currently don't have the time > to look closer into this, but we will do that when time allows us some > time in the future. > > Regards, > Rickard Green AO_compare_and_swap_full() for x86_64 in libatomic_ops has been reported as buggy: http://comments.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3732 I patched AO_compare_and_swap_full() in libatomic_ops-7.2alpha4 with the corrected version of fix number 2 by Patrick Marlier (see Patrick Marlier's second mail at the page mentioned above). After applying the fix, the previously hanging build succeeded. However, as mentioned earlier, on x86_64 libatomic_ops isn't needed. Regards, Rickard Green -- Rickard Green, Erlang/OTP, Ericsson AB. From gdiveglia@REDACTED Wed Sep 15 23:37:56 2010 From: gdiveglia@REDACTED (Gene Diveglia) Date: Wed, 15 Sep 2010 17:37:56 -0400 Subject: SSH problem in R14B Message-ID: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com> Hi, it appears something has broken with SSH key exchange in R14B. None of my ssh based CLI are working in R14B, but were previously working in R14A immediately prior to upgrading. I can replicate the problem easily using [otp_src]/lib/ssh/examples/ssh_sample_cli.erl. This sample program works with R14A under OS X 10.6.4 x86, but will fail if run under R14B. The ssh client used in both cases was also on OS X 10.6.4 and was used with defaults other than the port number. Standard ssh host key files which are functional under the OS were used in both cases. I also tried a set of host key files generated with a different version of ssh-keygen under linux. The error report under R14B follows. Kind regards, -Gene =ERROR REPORT==== 15-Sep-2010::17:18:48 === ** State machine <0.55.0> terminating ** Last message in was {tcp,#Port<0.1003>, <<0,0,0,140,6,30,0,0,0,128,65,149,33,196,247,233, 21,88,218,104,244,10,153,132,125,40,71,44,131, 253,22,245,12,59,92,79,134,177,95,51,154,41,176, 243,232,208,168,184,12,181,124,38,62,214,81,115, 50,11,63,233,1,35,154,219,53,185,15,122,237,207, 92,254,52,163,183,160,234,190,135,187,237,54,76, 129,219,210,144,186,203,125,92,60,144,43,145, 252,215,173,236,140,234,156,165,21,133,116,117, 100,130,233,22,62,184,117,253,60,161,185,80,36, 18,166,97,155,71,133,192,82,143,61,176,78,177, 99,138,116,239,183,0,0,0,0,0,0>>} ** When State == key_exchange ** Data == {state,tcp,gen_tcp,tcp_closed, {ssh,server, {undefined,{{0,0,0,0,0,65535,32512,1},61612}}, {2,0}, {2,0}, "SSH-2.0-OpenSSH_5.2","SSH-2.0-Erlang", <<20,12,57,149,244,18,127,223,192,251,128,85,91,196, 128,29,110,0,0,0,126,100,105,102,102,105,101,45,104, 101,108,108,109,97,110,45,103,114,111,117,112,45, 101,120,99,104,97,110,103,101,45,115,104,97,50,53, 54,44,100,105,102,102,105,101,45,104,101,108,108, 109,97,110,45,103,114,111,117,112,45,101,120,99,104, 97,110,103,101,45,115,104,97,49,44,100,105,102,102, 105,101,45,104,101,108,108,109,97,110,45,103,114, 111,117,112,49,52,45,115,104,97,49,44,100,105,102, 102,105,101,45,104,101,108,108,109,97,110,45,103, 114,111,117,112,49,45,115,104,97,49,0,0,0,15,115, 115,104,45,114,115,97,44,115,115,104,45,100,115,115, 0,0,0,157,97,101,115,49,50,56,45,99,116,114,44,97, 101,115,49,57,50,45,99,116,114,44,97,101,115,50,53, 54,45,99,116,114,44,97,114,99,102,111,117,114,50,53, 54,44,97,114,99,102,111,117,114,49,50,56,44,97,101, 115,49,50,56,45,99,98,99,44,51,100,101,115,45,99,98, 99,44,98,108,111,119,102,105,115,104,45,99,98,99,44, 99,97,115,116,49,50,56,45,99,98,99,44,97,101,115,49, 57,50,45,99,98,99,44,97,101,115,50,53,54,45,99,98, 99,44,97,114,99,102,111,117,114,44,114,105,106,110, 100,97,101,108,45,99,98,99,64,108,121,115,97,116, 111,114,46,108,105,117,46,115,101,0,0,0,157,97,101, 115,49,50,56,45,99,116,114,44,97,101,115,49,57,50, 45,99,116,114,44,97,101,115,50,53,54,45,99,116,114, 44,97,114,99,102,111,117,114,50,53,54,44,97,114,99, 102,111,117,114,49,50,56,44,97,101,115,49,50,56,45, 99,98,99,44,51,100,101,115,45,99,98,99,44,98,108, 111,119,102,105,115,104,45,99,98,99,44,99,97,115, 116,49,50,56,45,99,98,99,44,97,101,115,49,57,50,45, 99,98,99,44,97,101,115,50,53,54,45,99,98,99,44,97, 114,99,102,111,117,114,44,114,105,106,110,100,97, 101,108,45,99,98,99,64,108,121,115,97,116,111,114, 46,108,105,117,46,115,101,0,0,0,105,104,109,97,99, 45,109,100,53,44,104,109,97,99,45,115,104,97,49,44, 117,109,97,99,45,54,52,64,111,112,101,110,115,115, 104,46,99,111,109,44,104,109,97,99,45,114,105,112, 101,109,100,49,54,48,44,104,109,97,99,45,114,105, 112,101,109,100,49,54,48,64,111,112,101,110,115,115, 104,46,99,111,109,44,104,109,97,99,45,115,104,97,49, 45,57,54,44,104,109,97,99,45,109,100,53,45,57,54,0, 0,0,105,104,109,97,99,45,109,100,53,44,104,109,97, 99,45,115,104,97,49,44,117,109,97,99,45,54,52,64, 111,112,101,110,115,115,104,46,99,111,109,44,104, 109,97,99,45,114,105,112,101,109,100,49,54,48,44, 104,109,97,99,45,114,105,112,101,109,100,49,54,48, 64,111,112,101,110,115,115,104,46,99,111,109,44,104, 109,97,99,45,115,104,97,49,45,57,54,44,104,109,97, 99,45,109,100,53,45,57,54,0,0,0,26,110,111,110,101, 44,122,108,105,98,64,111,112,101,110,115,115,104,46, 99,111,109,44,122,108,105,98,0,0,0,26,110,111,110, 101,44,122,108,105,98,64,111,112,101,110,115,115, 104,46,99,111,109,44,122,108,105,98,0,0,0,0,0,0,0,0, 0,0,0,0,0>>, <<20,38,144,242,6,169,190,51,74,102,5,149,16,239,7,65, 57,0,0,0,26,100,105,102,102,105,101,45,104,101,108, 108,109,97,110,45,103,114,111,117,112,49,45,115,104, 97,49,0,0,0,7,115,115,104,45,100,115,115,0,0,0,19, 97,101,115,49,50,56,45,99,98,99,44,51,100,101,115, 45,99,98,99,0,0,0,19,97,101,115,49,50,56,45,99,98, 99,44,51,100,101,115,45,99,98,99,0,0,0,9,104,109,97, 99,45,115,104,97,49,0,0,0,9,104,109,97,99,45,115, 104,97,49,0,0,0,9,110,111,110,101,44,122,108,105,98, 0,0,0,9,110,111,110,101,44,122,108,105,98,0,0,0,0,0, 0,0,0,0,0,0,0,0>>, {alg,'diffie-hellman-group1-sha1','ssh-dss', 'hmac-sha1','hmac-sha1','aes128-cbc', 'aes128-cbc',none,none,none,none}, undefined,undefined,ssh_file,ssh_io,none,undefined,0, none,undefined,0,none,undefined,8,undefined,none, undefined,8,undefined,none,undefined,none,undefined, none,none,true,infinity,undefined,undefined, undefined, [{address,"ims"}, {port,2223}, {system_dir,"/Users/gene/erl_ssh"}, {shell,#Fun}, {role,server}], 1,1,undefined,undefined,undefined,undefined, undefined,"publickey,keyboard_interactive,password", undefined,undefined}, #Port<0.1003>,<<>>,<<>>,undefined, {ssh_msg_kexinit, <<127,229,163,177,131,154,163,20,128,32,226,34,154, 235,187,170>>, ["diffie-hellman-group1-sha1"], ["ssh-dss"], ["aes128-cbc","3des-cbc"], ["aes128-cbc","3des-cbc"], ["hmac-sha1"], ["hmac-sha1"], ["none","zlib"], ["none","zlib"], [],[],false,0}, false,<0.54.0>,undefined,undefined,undefined, [{address,"ims"}, {port,2223}, {system_dir,"/Users/gene/erl_ssh"}, {shell,#Fun}, {role,server}]} ** Reason for termination = ** {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, 87,111,15,213,167,162,93,159,122,170,251,197,236, 195,42,174,179,117,37,219,193,70,162,69,63,82, 132,149,99,206,90,198,153,34,211,176,14,89,142, 220,203,9,122,34,99,12,156,119,19,117,186,2,233, 151,22,31,96,153,210,219,121,225,207,231,39,246, 64,108,176,211,77,252,98,34,16,210,73,17,189,187, 193,111,191,143,115,49,60,159,218,245,67,241,2, 130,232,145,217,10,236,86,139,125,238,252,102, 246,213,110,249,125,80,182,210,55,229,163,214,91, 112,60,117,209,220,205,2,21,0,159,83,129,175,245, 131,186,139,165,18,35,133,43,148,124,202,31,9, 142,189,2,129,128,107,72,221,121,89,226,22,151, 35,105,202,173,197,168,100,60,58,6,23,223,9,121, 175,53,248,135,5,120,183,100,107,135,102,219,116, 63,213,17,149,118,142,19,143,204,168,236,49,165, 1,136,195,111,248,199,182,253,234,46,173,28,30, 114,240,8,77,176,107,184,41,108,183,172,165,202, 3,90,166,69,76,202,187,58,133,192,38,1,38,110, 212,36,18,35,149,58,218,69,134,143,42,1,174,19, 233,236,61,165,187,157,254,168,163,243,248,227, 110,122,213,72,107,214,220,212,99,245,106,120,91, 131,2,129,128,113,214,224,173,14,157,34,113,59, 116,57,129,233,210,114,12,213,159,133,106,34,130, 102,199,157,241,226,84,186,245,237,230,106,6,231, 231,140,208,106,53,74,56,77,48,92,112,47,91,236, 135,107,16,8,93,241,130,5,118,126,197,127,233, 238,199,226,7,79,225,193,139,174,87,11,168,190, 220,127,150,135,210,198,209,242,104,166,143,236, 18,125,22,64,26,53,139,45,219,45,144,236,245,193, 127,152,100,103,179,152,156,208,18,94,96,227,44, 151,136,194,77,114,12,70,223,143,194,196,204,101, 184,2,20,43,222,65,115,20,238,35,218,102,176,95, 196,101,68,47,163,229,153,49,118>>, not_encrypted}]} =ERROR REPORT==== 15-Sep-2010::17:18:48 === ** Generic server <0.52.0> terminating ** Last message in was {'EXIT',<0.55.0>, {error, [{'DSAPrivateKey', <<48,130,1,186,2,1,0,2,129,129,0,170,223, 146,206,87,111,15,213,167,162,93,159,122, 170,251,197,236,195,42,174,179,117,37, 219,193,70,162,69,63,82,132,149,99,206, 90,198,153,34,211,176,14,89,142,220,203, 9,122,34,99,12,156,119,19,117,186,2,233, 151,22,31,96,153,210,219,121,225,207,231, 39,246,64,108,176,211,77,252,98,34,16, 210,73,17,189,187,193,111,191,143,115,49, 60,159,218,245,67,241,2,130,232,145,217, 10,236,86,139,125,238,252,102,246,213, 110,249,125,80,182,210,55,229,163,214,91, 112,60,117,209,220,205,2,21,0,159,83,129, 175,245,131,186,139,165,18,35,133,43,148, 124,202,31,9,142,189,2,129,128,107,72, 221,121,89,226,22,151,35,105,202,173,197, 168,100,60,58,6,23,223,9,121,175,53,248, 135,5,120,183,100,107,135,102,219,116,63, 213,17,149,118,142,19,143,204,168,236,49, 165,1,136,195,111,248,199,182,253,234,46, 173,28,30,114,240,8,77,176,107,184,41, 108,183,172,165,202,3,90,166,69,76,202, 187,58,133,192,38,1,38,110,212,36,18,35, 149,58,218,69,134,143,42,1,174,19,233, 236,61,165,187,157,254,168,163,243,248, 227,110,122,213,72,107,214,220,212,99, 245,106,120,91,131,2,129,128,113,214,224, 173,14,157,34,113,59,116,57,129,233,210, 114,12,213,159,133,106,34,130,102,199, 157,241,226,84,186,245,237,230,106,6,231, 231,140,208,106,53,74,56,77,48,92,112,47, 91,236,135,107,16,8,93,241,130,5,118,126, 197,127,233,238,199,226,7,79,225,193,139, 174,87,11,168,190,220,127,150,135,210, 198,209,242,104,166,143,236,18,125,22,64, 26,53,139,45,219,45,144,236,245,193,127, 152,100,103,179,152,156,208,18,94,96,227, 44,151,136,194,77,114,12,70,223,143,194, 196,204,101,184,2,20,43,222,65,115,20, 238,35,218,102,176,95,196,101,68,47,163, 229,153,49,118>>, not_encrypted}]}} ** When Server state == {state,server,<0.54.0>,<0.55.0>,undefined} ** Reason for termination == ** {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, 87,111,15,213,167,162,93,159,122,170,251,197,236, 195,42,174,179,117,37,219,193,70,162,69,63,82, 132,149,99,206,90,198,153,34,211,176,14,89,142, 220,203,9,122,34,99,12,156,119,19,117,186,2,233, 151,22,31,96,153,210,219,121,225,207,231,39,246, 64,108,176,211,77,252,98,34,16,210,73,17,189,187, 193,111,191,143,115,49,60,159,218,245,67,241,2, 130,232,145,217,10,236,86,139,125,238,252,102, 246,213,110,249,125,80,182,210,55,229,163,214,91, 112,60,117,209,220,205,2,21,0,159,83,129,175,245, 131,186,139,165,18,35,133,43,148,124,202,31,9, 142,189,2,129,128,107,72,221,121,89,226,22,151, 35,105,202,173,197,168,100,60,58,6,23,223,9,121, 175,53,248,135,5,120,183,100,107,135,102,219,116, 63,213,17,149,118,142,19,143,204,168,236,49,165, 1,136,195,111,248,199,182,253,234,46,173,28,30, 114,240,8,77,176,107,184,41,108,183,172,165,202, 3,90,166,69,76,202,187,58,133,192,38,1,38,110, 212,36,18,35,149,58,218,69,134,143,42,1,174,19, 233,236,61,165,187,157,254,168,163,243,248,227, 110,122,213,72,107,214,220,212,99,245,106,120,91, 131,2,129,128,113,214,224,173,14,157,34,113,59, 116,57,129,233,210,114,12,213,159,133,106,34,130, 102,199,157,241,226,84,186,245,237,230,106,6,231, 231,140,208,106,53,74,56,77,48,92,112,47,91,236, 135,107,16,8,93,241,130,5,118,126,197,127,233, 238,199,226,7,79,225,193,139,174,87,11,168,190, 220,127,150,135,210,198,209,242,104,166,143,236, 18,125,22,64,26,53,139,45,219,45,144,236,245,193, 127,152,100,103,179,152,156,208,18,94,96,227,44, 151,136,194,77,114,12,70,223,143,194,196,204,101, 184,2,20,43,222,65,115,20,238,35,218,102,176,95, 196,101,68,47,163,229,153,49,118>>, not_encrypted}]} From zerthurd@REDACTED Thu Sep 16 01:12:52 2010 From: zerthurd@REDACTED (Maxim Treskin) Date: Thu, 16 Sep 2010 06:12:52 +0700 Subject: [erlang-bugs] SSH problem in R14B In-Reply-To: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com> References: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com> Message-ID: Yes, have the same on Gentoo Linux amd64 On 16 September 2010 04:37, Gene Diveglia wrote: > > Hi, it appears something has broken with SSH key exchange in R14B. None of > my ssh based CLI are working in R14B, but were previously working in R14A > immediately prior to upgrading. I can replicate the problem easily using > [otp_src]/lib/ssh/examples/ssh_sample_cli.erl. This sample program works > with R14A under OS X 10.6.4 x86, but will fail if run under R14B. The ssh > client used in both cases was also on OS X 10.6.4 and was used with defaults > other than the port number. Standard ssh host key files which are > functional under the OS were used in both cases. I also tried a set of host > key files generated with a different version of ssh-keygen under linux. The > error report under R14B follows. > > Kind regards, > > -Gene > > =ERROR REPORT==== 15-Sep-2010::17:18:48 === > ** State machine <0.55.0> terminating > ** Last message in was {tcp,#Port<0.1003>, > > <<0,0,0,140,6,30,0,0,0,128,65,149,33,196,247,233, > 21,88,218,104,244,10,153,132,125,40,71,44,131, > > 253,22,245,12,59,92,79,134,177,95,51,154,41,176, > > 243,232,208,168,184,12,181,124,38,62,214,81,115, > > 50,11,63,233,1,35,154,219,53,185,15,122,237,207, > > 92,254,52,163,183,160,234,190,135,187,237,54,76, > 129,219,210,144,186,203,125,92,60,144,43,145, > > 252,215,173,236,140,234,156,165,21,133,116,117, > > 100,130,233,22,62,184,117,253,60,161,185,80,36, > 18,166,97,155,71,133,192,82,143,61,176,78,177, > 99,138,116,239,183,0,0,0,0,0,0>>} > ** When State == key_exchange > ** Data == {state,tcp,gen_tcp,tcp_closed, > {ssh,server, > {undefined,{{0,0,0,0,0,65535,32512,1},61612}}, > {2,0}, > {2,0}, > "SSH-2.0-OpenSSH_5.2","SSH-2.0-Erlang", > > <<20,12,57,149,244,18,127,223,192,251,128,85,91,196, > > 128,29,110,0,0,0,126,100,105,102,102,105,101,45,104, > 101,108,108,109,97,110,45,103,114,111,117,112,45, > > 101,120,99,104,97,110,103,101,45,115,104,97,50,53, > 54,44,100,105,102,102,105,101,45,104,101,108,108, > > 109,97,110,45,103,114,111,117,112,45,101,120,99,104, > > 97,110,103,101,45,115,104,97,49,44,100,105,102,102, > 105,101,45,104,101,108,108,109,97,110,45,103,114, > > 111,117,112,49,52,45,115,104,97,49,44,100,105,102, > 102,105,101,45,104,101,108,108,109,97,110,45,103, > 114,111,117,112,49,45,115,104,97,49,0,0,0,15,115, > > 115,104,45,114,115,97,44,115,115,104,45,100,115,115, > > 0,0,0,157,97,101,115,49,50,56,45,99,116,114,44,97, > > 101,115,49,57,50,45,99,116,114,44,97,101,115,50,53, > > 54,45,99,116,114,44,97,114,99,102,111,117,114,50,53, > > 54,44,97,114,99,102,111,117,114,49,50,56,44,97,101, > > 115,49,50,56,45,99,98,99,44,51,100,101,115,45,99,98, > > 99,44,98,108,111,119,102,105,115,104,45,99,98,99,44, > > 99,97,115,116,49,50,56,45,99,98,99,44,97,101,115,49, > > 57,50,45,99,98,99,44,97,101,115,50,53,54,45,99,98, > > 99,44,97,114,99,102,111,117,114,44,114,105,106,110, > 100,97,101,108,45,99,98,99,64,108,121,115,97,116, > > 111,114,46,108,105,117,46,115,101,0,0,0,157,97,101, > > 115,49,50,56,45,99,116,114,44,97,101,115,49,57,50, > > 45,99,116,114,44,97,101,115,50,53,54,45,99,116,114, > > 44,97,114,99,102,111,117,114,50,53,54,44,97,114,99, > > 102,111,117,114,49,50,56,44,97,101,115,49,50,56,45, > 99,98,99,44,51,100,101,115,45,99,98,99,44,98,108, > 111,119,102,105,115,104,45,99,98,99,44,99,97,115, > > 116,49,50,56,45,99,98,99,44,97,101,115,49,57,50,45, > > 99,98,99,44,97,101,115,50,53,54,45,99,98,99,44,97, > 114,99,102,111,117,114,44,114,105,106,110,100,97, > > 101,108,45,99,98,99,64,108,121,115,97,116,111,114, > > 46,108,105,117,46,115,101,0,0,0,105,104,109,97,99, > > 45,109,100,53,44,104,109,97,99,45,115,104,97,49,44, > > 117,109,97,99,45,54,52,64,111,112,101,110,115,115, > > 104,46,99,111,109,44,104,109,97,99,45,114,105,112, > 101,109,100,49,54,48,44,104,109,97,99,45,114,105, > > 112,101,109,100,49,54,48,64,111,112,101,110,115,115, > > 104,46,99,111,109,44,104,109,97,99,45,115,104,97,49, > > 45,57,54,44,104,109,97,99,45,109,100,53,45,57,54,0, > > 0,0,105,104,109,97,99,45,109,100,53,44,104,109,97, > 99,45,115,104,97,49,44,117,109,97,99,45,54,52,64, > 111,112,101,110,115,115,104,46,99,111,109,44,104, > 109,97,99,45,114,105,112,101,109,100,49,54,48,44, > > 104,109,97,99,45,114,105,112,101,109,100,49,54,48, > > 64,111,112,101,110,115,115,104,46,99,111,109,44,104, > > 109,97,99,45,115,104,97,49,45,57,54,44,104,109,97, > > 99,45,109,100,53,45,57,54,0,0,0,26,110,111,110,101, > > 44,122,108,105,98,64,111,112,101,110,115,115,104,46, > > 99,111,109,44,122,108,105,98,0,0,0,26,110,111,110, > 101,44,122,108,105,98,64,111,112,101,110,115,115, > > 104,46,99,111,109,44,122,108,105,98,0,0,0,0,0,0,0,0, > 0,0,0,0,0>>, > > <<20,38,144,242,6,169,190,51,74,102,5,149,16,239,7,65, > > 57,0,0,0,26,100,105,102,102,105,101,45,104,101,108, > > 108,109,97,110,45,103,114,111,117,112,49,45,115,104, > > 97,49,0,0,0,7,115,115,104,45,100,115,115,0,0,0,19, > > 97,101,115,49,50,56,45,99,98,99,44,51,100,101,115, > > 45,99,98,99,0,0,0,19,97,101,115,49,50,56,45,99,98, > > 99,44,51,100,101,115,45,99,98,99,0,0,0,9,104,109,97, > 99,45,115,104,97,49,0,0,0,9,104,109,97,99,45,115, > > 104,97,49,0,0,0,9,110,111,110,101,44,122,108,105,98, > > 0,0,0,9,110,111,110,101,44,122,108,105,98,0,0,0,0,0, > 0,0,0,0,0,0,0,0>>, > {alg,'diffie-hellman-group1-sha1','ssh-dss', > 'hmac-sha1','hmac-sha1','aes128-cbc', > 'aes128-cbc',none,none,none,none}, > > undefined,undefined,ssh_file,ssh_io,none,undefined,0, > none,undefined,0,none,undefined,8,undefined,none, > > undefined,8,undefined,none,undefined,none,undefined, > none,none,true,infinity,undefined,undefined, > undefined, > [{address,"ims"}, > {port,2223}, > {system_dir,"/Users/gene/erl_ssh"}, > {shell,#Fun}, > {role,server}], > 1,1,undefined,undefined,undefined,undefined, > > undefined,"publickey,keyboard_interactive,password", > undefined,undefined}, > #Port<0.1003>,<<>>,<<>>,undefined, > {ssh_msg_kexinit, > <<127,229,163,177,131,154,163,20,128,32,226,34,154, > 235,187,170>>, > ["diffie-hellman-group1-sha1"], > ["ssh-dss"], > ["aes128-cbc","3des-cbc"], > ["aes128-cbc","3des-cbc"], > ["hmac-sha1"], > ["hmac-sha1"], > ["none","zlib"], > ["none","zlib"], > [],[],false,0}, > false,<0.54.0>,undefined,undefined,undefined, > [{address,"ims"}, > {port,2223}, > {system_dir,"/Users/gene/erl_ssh"}, > {shell,#Fun}, > {role,server}]} > ** Reason for termination = > ** > {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, > > 87,111,15,213,167,162,93,159,122,170,251,197,236, > 195,42,174,179,117,37,219,193,70,162,69,63,82, > > 132,149,99,206,90,198,153,34,211,176,14,89,142, > > 220,203,9,122,34,99,12,156,119,19,117,186,2,233, > > 151,22,31,96,153,210,219,121,225,207,231,39,246, > > 64,108,176,211,77,252,98,34,16,210,73,17,189,187, > > 193,111,191,143,115,49,60,159,218,245,67,241,2, > 130,232,145,217,10,236,86,139,125,238,252,102, > > 246,213,110,249,125,80,182,210,55,229,163,214,91, > > 112,60,117,209,220,205,2,21,0,159,83,129,175,245, > 131,186,139,165,18,35,133,43,148,124,202,31,9, > > 142,189,2,129,128,107,72,221,121,89,226,22,151, > > 35,105,202,173,197,168,100,60,58,6,23,223,9,121, > > 175,53,248,135,5,120,183,100,107,135,102,219,116, > > 63,213,17,149,118,142,19,143,204,168,236,49,165, > > 1,136,195,111,248,199,182,253,234,46,173,28,30, > > 114,240,8,77,176,107,184,41,108,183,172,165,202, > 3,90,166,69,76,202,187,58,133,192,38,1,38,110, > > 212,36,18,35,149,58,218,69,134,143,42,1,174,19, > > 233,236,61,165,187,157,254,168,163,243,248,227, > > 110,122,213,72,107,214,220,212,99,245,106,120,91, > > 131,2,129,128,113,214,224,173,14,157,34,113,59, > > 116,57,129,233,210,114,12,213,159,133,106,34,130, > > 102,199,157,241,226,84,186,245,237,230,106,6,231, > > 231,140,208,106,53,74,56,77,48,92,112,47,91,236, > 135,107,16,8,93,241,130,5,118,126,197,127,233, > > 238,199,226,7,79,225,193,139,174,87,11,168,190, > > 220,127,150,135,210,198,209,242,104,166,143,236, > > 18,125,22,64,26,53,139,45,219,45,144,236,245,193, > > 127,152,100,103,179,152,156,208,18,94,96,227,44, > > 151,136,194,77,114,12,70,223,143,194,196,204,101, > > 184,2,20,43,222,65,115,20,238,35,218,102,176,95, > 196,101,68,47,163,229,153,49,118>>, > not_encrypted}]} > > =ERROR REPORT==== 15-Sep-2010::17:18:48 === > ** Generic server <0.52.0> terminating > ** Last message in was {'EXIT',<0.55.0>, > {error, > [{'DSAPrivateKey', > > <<48,130,1,186,2,1,0,2,129,129,0,170,223, > > 146,206,87,111,15,213,167,162,93,159,122, > 170,251,197,236,195,42,174,179,117,37, > > 219,193,70,162,69,63,82,132,149,99,206, > > 90,198,153,34,211,176,14,89,142,220,203, > > 9,122,34,99,12,156,119,19,117,186,2,233, > > 151,22,31,96,153,210,219,121,225,207,231, > 39,246,64,108,176,211,77,252,98,34,16, > > 210,73,17,189,187,193,111,191,143,115,49, > > 60,159,218,245,67,241,2,130,232,145,217, > 10,236,86,139,125,238,252,102,246,213, > > 110,249,125,80,182,210,55,229,163,214,91, > > 112,60,117,209,220,205,2,21,0,159,83,129, > > 175,245,131,186,139,165,18,35,133,43,148, > 124,202,31,9,142,189,2,129,128,107,72, > > 221,121,89,226,22,151,35,105,202,173,197, > > 168,100,60,58,6,23,223,9,121,175,53,248, > > 135,5,120,183,100,107,135,102,219,116,63, > > 213,17,149,118,142,19,143,204,168,236,49, > > 165,1,136,195,111,248,199,182,253,234,46, > 173,28,30,114,240,8,77,176,107,184,41, > > 108,183,172,165,202,3,90,166,69,76,202, > > 187,58,133,192,38,1,38,110,212,36,18,35, > 149,58,218,69,134,143,42,1,174,19,233, > > 236,61,165,187,157,254,168,163,243,248, > 227,110,122,213,72,107,214,220,212,99, > > 245,106,120,91,131,2,129,128,113,214,224, > > 173,14,157,34,113,59,116,57,129,233,210, > 114,12,213,159,133,106,34,130,102,199, > > 157,241,226,84,186,245,237,230,106,6,231, > > 231,140,208,106,53,74,56,77,48,92,112,47, > > 91,236,135,107,16,8,93,241,130,5,118,126, > > 197,127,233,238,199,226,7,79,225,193,139, > 174,87,11,168,190,220,127,150,135,210, > > 198,209,242,104,166,143,236,18,125,22,64, > > 26,53,139,45,219,45,144,236,245,193,127, > > 152,100,103,179,152,156,208,18,94,96,227, > > 44,151,136,194,77,114,12,70,223,143,194, > 196,204,101,184,2,20,43,222,65,115,20, > > 238,35,218,102,176,95,196,101,68,47,163, > 229,153,49,118>>, > not_encrypted}]}} > ** When Server state == {state,server,<0.54.0>,<0.55.0>,undefined} > ** Reason for termination == > ** > {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, > > 87,111,15,213,167,162,93,159,122,170,251,197,236, > 195,42,174,179,117,37,219,193,70,162,69,63,82, > > 132,149,99,206,90,198,153,34,211,176,14,89,142, > > 220,203,9,122,34,99,12,156,119,19,117,186,2,233, > > 151,22,31,96,153,210,219,121,225,207,231,39,246, > > 64,108,176,211,77,252,98,34,16,210,73,17,189,187, > > 193,111,191,143,115,49,60,159,218,245,67,241,2, > 130,232,145,217,10,236,86,139,125,238,252,102, > > 246,213,110,249,125,80,182,210,55,229,163,214,91, > > 112,60,117,209,220,205,2,21,0,159,83,129,175,245, > 131,186,139,165,18,35,133,43,148,124,202,31,9, > > 142,189,2,129,128,107,72,221,121,89,226,22,151, > > 35,105,202,173,197,168,100,60,58,6,23,223,9,121, > > 175,53,248,135,5,120,183,100,107,135,102,219,116, > > 63,213,17,149,118,142,19,143,204,168,236,49,165, > > 1,136,195,111,248,199,182,253,234,46,173,28,30, > > 114,240,8,77,176,107,184,41,108,183,172,165,202, > 3,90,166,69,76,202,187,58,133,192,38,1,38,110, > > 212,36,18,35,149,58,218,69,134,143,42,1,174,19, > > 233,236,61,165,187,157,254,168,163,243,248,227, > > 110,122,213,72,107,214,220,212,99,245,106,120,91, > > 131,2,129,128,113,214,224,173,14,157,34,113,59, > > 116,57,129,233,210,114,12,213,159,133,106,34,130, > > 102,199,157,241,226,84,186,245,237,230,106,6,231, > > 231,140,208,106,53,74,56,77,48,92,112,47,91,236, > 135,107,16,8,93,241,130,5,118,126,197,127,233, > > 238,199,226,7,79,225,193,139,174,87,11,168,190, > > 220,127,150,135,210,198,209,242,104,166,143,236, > > 18,125,22,64,26,53,139,45,219,45,144,236,245,193, > > 127,152,100,103,179,152,156,208,18,94,96,227,44, > > 151,136,194,77,114,12,70,223,143,194,196,204,101, > > 184,2,20,43,222,65,115,20,238,35,218,102,176,95, > 196,101,68,47,163,229,153,49,118>>, > not_encrypted}]} > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- Maxim Treskin From kostis@REDACTED Thu Sep 16 09:11:10 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 16 Sep 2010 10:11:10 +0300 Subject: [erlang-bugs] illegal declaration of pertially defined record types in dialyzer, R14A In-Reply-To: <201008311526.18180.kruber@zib.de> References: <201008311526.18180.kruber@zib.de> Message-ID: <4C91C30E.10004@cs.ntua.gr> Nico Kruber wrote: > here's the other bug I originally intendet to report: > > I declare a remote type rec1:rec1() in the rec1 module, > a record rec2 in module rec2 along with a rec2:rec2() type. > > If I use the rec2:rec2() type in a third module, i.e. rec3, dialyzer reports > an illegal declaration of rec2#{id}: > > ------------------------ >> dialyzer -Werror_handling -Wrace_conditions --src -c rec*.erl --no_native > Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes > Proceeding with analysis... > dialyzer: Analysis failed with error: Illegal declaration of rec2#{id} > > Last messages in the log cache: > Reading files and computing callgraph... done in 0.06 secs > Removing edges... done in 0.01 secs > ------------------------ This problem has now been fixed (thanks to Maria Christakis). The fix appears here: http://github.com/kostis/otp/commit/544b05dc65606fcbfb46c2df69026c28f4ab2117 and will hopefully be included in OTP at some point. Kostis From kostis@REDACTED Thu Sep 16 09:12:31 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 16 Sep 2010 10:12:31 +0300 Subject: [erlang-bugs] nocatch error in dialyzer, R14A In-Reply-To: <201008311502.10956.kruber@zib.de> References: <201008311459.09585.kruber@zib.de> <201008311502.10956.kruber@zib.de> Message-ID: <4C91C35F.1050905@cs.ntua.gr> Nico Kruber wrote: > On Tuesday 31 August 2010 14:59:02 Nico Kruber wrote: >> While I was trying to make a minimal example for another strange behaviour >> of the dialyzer I found the following bug calling >> >> .... >> dialyzer: Analysis failed with error: {{nocatch,{error, >> [73,108,108,101,103,97|...]}}, >> [{erl_types,record_from_form,5}, >> {erl_types,t_from_form,3}, >> {erl_types,'-t_opaque_from_records/1-anonymous-2-',3}, >> {dict,map_bucket,2}, >> {dict,map_bkt_list,2}, >> {dict,map_bkt_list,2}, >> {dict,map_seg_list,...}, >> {dict,...}]} >> Last messages in the log cache: >> Reading files and computing callgraph... done in 0.06 secs >> Removing edges... done in 0.01 secs >> Typesig analysis for SCC: [{rec2,module_info,1}] This problem has now been fixed (thanks to Maria Christakis). The fix appears here: http://github.com/kostis/otp/commit/544b05dc65606fcbfb46c2df69026c28f4ab2117 and will hopefully be included in OTP at some point. Kostis From fdmanana@REDACTED Fri Sep 17 03:11:17 2010 From: fdmanana@REDACTED (Filipe David Manana) Date: Fri, 17 Sep 2010 02:11:17 +0100 Subject: possible bug in ssl and/or public_key module (R13 and R14) Message-ID: When connecting to particular server, though an ssl socket, I always get the error: Erlang R14B (erts-5.8.1) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.1 (abort with ^G) 1> c(test_ssl). {ok,test_ssl} 2> test_ssl:test(). =ERROR REPORT==== 17-Sep-2010::02:07:25 === SSL: certify_certificate: ./ssl_handshake.erl:502:Fatal error: handshake failure ** exception error: no match of right hand side value {error,esslconnect} in function test_ssl:test/0 3> However, if I pick up another server, like www.cia.gov:443 or www.facebook.com:443 for example, it succeeds (with exactly the same ssl options passed to ssl:connect/3). Also tested with R13B03 and R13B04 and got the same results (only modified value of option verify from verify_none to 0). The code to test this eventual bug is: -module(test_ssl). -compile(export_all). -define(HOST, "couchdb.staging.one.ubuntu.com"). % -define(HOST, "www.cia.gov"). test() -> Body = iolist_to_binary([ "GET / HTTP/1.1\r\n", "Host: ", ?HOST, "\r\n", "Accept: */*\r\n", "Connection: close\r\n", "\r\n" ]), application:start(crypto), application:start(public_key), application:start(ssl), Options = [ {ssl_imp, new}, binary, {nodelay, true}, {active, false}, {verify, verify_none} % {verify_fun, fun(_) -> true end}, ], {ok, S} = ssl:connect(?HOST, 443, Options), ok = ssl:send(S, Body), loop(S), ssl:close(S). loop(S) -> ssl:setopts(S, [{active, once}]), receive {ssl, S, Data} -> io:format("received data: ~p~n", [Data]), loop(S); {ssl_closed, S} -> io:format("socket closed", []); {ssl_error, S, Error} -> io:format("socket error: ~p", [Error]) end. cheers -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From Bernhard.Lichtinger@REDACTED Fri Sep 17 10:15:05 2010 From: Bernhard.Lichtinger@REDACTED (Lichtinger, Bernhard) Date: Fri, 17 Sep 2010 10:15:05 +0200 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: Message-ID: <34DC8EF7-88C7-459F-9E92-D9EBF0500935@lrz.de> Hi, You have to add the ssloption {depth,3} in this case, as "couchdb.staging.one.ubuntu.com" has a certificate chain of depth 3 and default depth is 1. > Options = [ > {ssl_imp, new}, > binary, > {nodelay, true}, > {active, false}, > {verify, verify_none}, {depth,3} > % {verify_fun, fun(_) -> true end}, > ], The "SSL: certify_certificate: ./ssl_handshake.erl:502:Fatal error: handshake failure" results of reaching the maximum depth in certificate chain check and if the certificate at the maximum depth is not from a CA, the certificate check returns an error and the ssl handshake fails. Regards, Bernhard Lichtinger From ingela@REDACTED Fri Sep 17 10:19:43 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Fri, 17 Sep 2010 10:19:43 +0200 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: Message-ID: <4C93249F.3040408@erix.ericsson.se> Hi! Humm ... I get this result running your program: Erlang R14B (erts-5.8.1) [source] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] Eshell V5.8.1 (abort with ^G) 1> c(ssl_test). {ok,ssl_test} 2> ssl_test:test(). =ERROR REPORT==== 17-Sep-2010::09:22:46 === SSL: certify_certificate: ./ssl_handshake.erl:570:Fatal error: certificate expired ** exception error: no match of right hand side value {error,"certificate expired"} in function ssl_test:test/0 Did you run your test on a github version of a R14B to be? I do not see how you could get a completely different error. If I do FunAndState = {fun(_,{bad_cert, unknown_ca}, UserState) -> {valid, UserState}; (_,{bad_cert, cert_expired}, UserState) -> {valid, UserState}; (_,{bad_cert, _} = Reason, _) -> {fail, Reason}; (_,{extension, _}, UserState) -> {unknown, UserState}; (_, valid, UserState) -> {valid, UserState} end, []}. ssl:connect(couchdb.staging.one.ubuntu.com, 443, [{verify, verify_peer}, {verify_fun, FunAndState}]). I get a connection. (I.e I accept that the certificate has expired) However ssl:connect(couchdb.staging.one.ubuntu.com, 443, [{verify, 0}, {ssl_imp, old}]). will give a connection so it seems {verify, 0} is more forgiving than {verify, verify_none} that only allows the path error unkonwn_ca at the moment, maybe we have to rethink that for backwards compatibility reasons. Regards Ingela Erlang/OTP team - Ericsson AB Filipe David Manana wrote: > When connecting to particular server, though an ssl socket, I always get the > error: > > Erlang R14B (erts-5.8.1) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] > [kernel-poll:false] > > Eshell V5.8.1 (abort with ^G) > 1> c(test_ssl). > {ok,test_ssl} > 2> test_ssl:test(). > > =ERROR REPORT==== 17-Sep-2010::02:07:25 === > SSL: certify_certificate: ./ssl_handshake.erl:502:Fatal error: handshake > failure > ** exception error: no match of right hand side value {error,esslconnect} > in function test_ssl:test/0 > 3> > > However, if I pick up another server, like www.cia.gov:443 or > www.facebook.com:443 for example, it succeeds (with exactly the same ssl > options passed to ssl:connect/3). > Also tested with R13B03 and R13B04 and got the same results (only modified > value of option verify from verify_none to 0). > > The code to test this eventual bug is: > > -module(test_ssl). > -compile(export_all). > > -define(HOST, "couchdb.staging.one.ubuntu.com"). > % -define(HOST, "www.cia.gov"). > > test() -> > Body = iolist_to_binary([ > "GET / HTTP/1.1\r\n", > "Host: ", ?HOST, "\r\n", > "Accept: */*\r\n", > "Connection: close\r\n", "\r\n" > ]), > application:start(crypto), > application:start(public_key), > application:start(ssl), > Options = [ > {ssl_imp, new}, > binary, > {nodelay, true}, > {active, false}, > {verify, verify_none} > % {verify_fun, fun(_) -> true end}, > ], > {ok, S} = ssl:connect(?HOST, 443, Options), > ok = ssl:send(S, Body), > loop(S), > ssl:close(S). > > loop(S) -> > ssl:setopts(S, [{active, once}]), > receive > {ssl, S, Data} -> > io:format("received data: ~p~n", [Data]), > loop(S); > {ssl_closed, S} -> > io:format("socket closed", []); > {ssl_error, S, Error} -> > io:format("socket error: ~p", [Error]) > end. > > > cheers > > From fauli@REDACTED Fri Sep 17 13:06:02 2010 From: fauli@REDACTED (Christian Faulhammer) Date: Fri, 17 Sep 2010 13:06:02 +0200 Subject: aclocal fails in lib subdir of Erlang 14B Message-ID: <20100917130602.718e49d8@gentoo.org> Hi, when running aclocal in the lib/ subdir of the shipped source tarball of 14B, it will fail because of missing configure.in. Copying over lib/configure.in.src lets it pass. Thanks for the attention. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From fauli@REDACTED Fri Sep 17 13:06:53 2010 From: fauli@REDACTED (Christian Faulhammer) Date: Fri, 17 Sep 2010 13:06:53 +0200 Subject: [erlang-bugs] Build system ignores custom LDFLAGS In-Reply-To: <20100906192636.27593a47@gentoo.org> References: <20100906192636.27593a47@gentoo.org> Message-ID: <20100917130653.0308d6b3@gentoo.org> Hi, Christian Faulhammer : > as a follow-up to the thread starting in > http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1249, I would like to report > an issue with the megaco_flex Makefile in 14A, ignoring custom > LDFLAGS. A patch has been reported in above thread, where this exact > issue got already fixed, but only partly taken over. Please apply the > attached patch to the release branch. This has not been fixed in the final version of 14B. Any reason or was it just overlooked? V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From fdmanana@REDACTED Fri Sep 17 14:04:59 2010 From: fdmanana@REDACTED (Filipe David Manana) Date: Fri, 17 Sep 2010 13:04:59 +0100 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: <4C93249F.3040408@erix.ericsson.se> References: <4C93249F.3040408@erix.ericsson.se> Message-ID: Both approaches worked for me: 1) adding {depth, 3} (weird that it's necessary when {verify, verify_none} is passed) 2) adding the verify_fun option that Ingela wrote thank you both On Fri, Sep 17, 2010 at 9:19 AM, Ingela Anderton Andin < ingela@REDACTED> wrote: > Hi! > > Humm ... > > I get this result running your program: > > Erlang R14B (erts-5.8.1) [source] [smp:4:4] [rq:4] [async-threads:0] > [kernel-poll:false] > > > Eshell V5.8.1 (abort with ^G) > 1> c(ssl_test). > {ok,ssl_test} > 2> ssl_test:test(). > > =ERROR REPORT==== 17-Sep-2010::09:22:46 === > SSL: certify_certificate: ./ssl_handshake.erl:570:Fatal error: certificate > expired > ** exception error: no match of right hand side value {error,"certificate > expired"} > in function ssl_test:test/0 > > > Did you run your test on a github version of a R14B to be? I do not see how > you could get > a completely different error. > > If I do > > FunAndState = {fun(_,{bad_cert, unknown_ca}, UserState) -> {valid, > UserState}; (_,{bad_cert, cert_expired}, UserState) -> {valid, UserState}; > (_,{bad_cert, _} = Reason, _) -> {fail, Reason}; (_,{extension, _}, > UserState) -> {unknown, UserState}; (_, valid, UserState) -> {valid, > UserState} end, []}. > > ssl:connect(couchdb.staging.one.ubuntu.com, 443, [{verify, verify_peer}, > {verify_fun, FunAndState}]). > > I get a connection. (I.e I accept that the certificate has expired) > > However ssl:connect(couchdb.staging.one.ubuntu.com, 443, [{verify, 0}, > {ssl_imp, old}]). > > will give a connection so it seems {verify, 0} is more forgiving than > {verify, verify_none} that only allows the path error unkonwn_ca > at the moment, maybe we have to rethink that for backwards compatibility > reasons. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > Filipe David Manana wrote: > >> When connecting to particular server, though an ssl socket, I always get >> the >> error: >> >> Erlang R14B (erts-5.8.1) [source] [smp:2:2] [rq:2] [async-threads:0] >> [hipe] >> [kernel-poll:false] >> >> Eshell V5.8.1 (abort with ^G) >> 1> c(test_ssl). >> {ok,test_ssl} >> 2> test_ssl:test(). >> >> =ERROR REPORT==== 17-Sep-2010::02:07:25 === >> SSL: certify_certificate: ./ssl_handshake.erl:502:Fatal error: handshake >> failure >> ** exception error: no match of right hand side value {error,esslconnect} >> in function test_ssl:test/0 >> 3> >> >> However, if I pick up another server, like www.cia.gov:443 or >> www.facebook.com:443 for example, it succeeds (with exactly the same ssl >> options passed to ssl:connect/3). >> Also tested with R13B03 and R13B04 and got the same results (only modified >> value of option verify from verify_none to 0). >> >> The code to test this eventual bug is: >> >> -module(test_ssl). >> -compile(export_all). >> >> -define(HOST, "couchdb.staging.one.ubuntu.com"). >> % -define(HOST, "www.cia.gov"). >> >> test() -> >> Body = iolist_to_binary([ >> "GET / HTTP/1.1\r\n", >> "Host: ", ?HOST, "\r\n", >> "Accept: */*\r\n", >> "Connection: close\r\n", "\r\n" >> ]), >> application:start(crypto), >> application:start(public_key), >> application:start(ssl), >> Options = [ >> {ssl_imp, new}, >> binary, >> {nodelay, true}, >> {active, false}, >> {verify, verify_none} >> % {verify_fun, fun(_) -> true end}, >> ], >> {ok, S} = ssl:connect(?HOST, 443, Options), >> ok = ssl:send(S, Body), >> loop(S), >> ssl:close(S). >> >> loop(S) -> >> ssl:setopts(S, [{active, once}]), >> receive >> {ssl, S, Data} -> >> io:format("received data: ~p~n", [Data]), >> loop(S); >> {ssl_closed, S} -> >> io:format("socket closed", []); >> {ssl_error, S, Error} -> >> io:format("socket error: ~p", [Error]) >> end. >> >> >> cheers >> >> >> > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From fdmanana@REDACTED Fri Sep 17 19:53:38 2010 From: fdmanana@REDACTED (Filipe David Manana) Date: Fri, 17 Sep 2010 18:53:38 +0100 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: <4C93249F.3040408@erix.ericsson.se> Message-ID: Just a few more questions, 1) are the 'verify_fun' and 'cacertfile' options meant to be used together or are they mutually exclusive? 2) Trying to do this on Ubuntu: {cacertfile, "/etc/ssl/certs/ca-certificates.crt"} That file, is a list o PEM encoded certificate: $ file /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt: PEM certificate However I get the following exception when I pass that option: ** exception error: no match of right hand side value {error,ecacertfile} in function ssl_test:test/0 =ERROR REPORT==== 17-Sep-2010::18:33:04 === SSL: 1056: error:{error, {badmatch, {error, {asn1, {'Type not compatible with table constraint', {{badmatch,{error,{asn1,{wrong_tag,{5,16}}}}}, [{'OTP-PUB-KEY','dec_Dss-Parms',2}, {'OTP-PUB-KEY',dec_SignatureAlgorithm,2}, {'OTP-PUB-KEY',dec_OTPTBSCertificate,2}, {'OTP-PUB-KEY',dec_OTPCertificate,2}, {'OTP-PUB-KEY',decode,2}, {pubkey_cert_records,decode_cert,1}, {public_key,pkix_decode_cert,2}, {ssl_certificate_db,add_certs,3}]}}}}}} /etc/ssl/certs/ca-certificates.crt [{ssl_connection,init_certificates,2}, {ssl_connection,ssl_init,2}, {ssl_connection,init,1}, {gen_fsm,init_it,6}, {proc_lib,init_p_do_apply,3}] Is this a bug? The ssl man page mentions the file is in the PEM format. The file contents can be looked at: http://friendpaste.com/4lQn7yihrUa4fE2Vs4u7JS 3) For the verify function, it receives {bad_cert, unknown_ca} when a certificate is self-signed? I would like to distinguish between unknown CAs and self-signed certificates (certificate signed by the target host). cheers On Fri, Sep 17, 2010 at 1:04 PM, Filipe David Manana wrote: > Both approaches worked for me: > > 1) adding {depth, 3} (weird that it's necessary when {verify, > verify_none} is passed) > > 2) adding the verify_fun option that Ingela wrote > > thank you both > > > On Fri, Sep 17, 2010 at 9:19 AM, Ingela Anderton Andin < > ingela@REDACTED> wrote: > >> Hi! >> >> Humm ... >> >> I get this result running your program: >> >> Erlang R14B (erts-5.8.1) [source] [smp:4:4] [rq:4] [async-threads:0] >> [kernel-poll:false] >> >> >> Eshell V5.8.1 (abort with ^G) >> 1> c(ssl_test). >> {ok,ssl_test} >> 2> ssl_test:test(). >> >> =ERROR REPORT==== 17-Sep-2010::09:22:46 === >> SSL: certify_certificate: ./ssl_handshake.erl:570:Fatal error: certificate >> expired >> ** exception error: no match of right hand side value {error,"certificate >> expired"} >> in function ssl_test:test/0 >> >> >> Did you run your test on a github version of a R14B to be? I do not see >> how you could get >> a completely different error. >> >> If I do >> >> FunAndState = {fun(_,{bad_cert, unknown_ca}, UserState) -> {valid, >> UserState}; (_,{bad_cert, cert_expired}, UserState) -> {valid, UserState}; >> (_,{bad_cert, _} = Reason, _) -> {fail, Reason}; (_,{extension, _}, >> UserState) -> {unknown, UserState}; (_, valid, UserState) -> {valid, >> UserState} end, []}. >> >> ssl:connect(couchdb.staging.one.ubuntu.com, 443, [{verify, verify_peer}, >> {verify_fun, FunAndState}]). >> >> I get a connection. (I.e I accept that the certificate has expired) >> >> However ssl:connect(couchdb.staging.one.ubuntu.com, 443, [{verify, 0}, >> {ssl_imp, old}]). >> >> will give a connection so it seems {verify, 0} is more forgiving than >> {verify, verify_none} that only allows the path error unkonwn_ca >> at the moment, maybe we have to rethink that for backwards compatibility >> reasons. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> Filipe David Manana wrote: >> >>> When connecting to particular server, though an ssl socket, I always get >>> the >>> error: >>> >>> Erlang R14B (erts-5.8.1) [source] [smp:2:2] [rq:2] [async-threads:0] >>> [hipe] >>> [kernel-poll:false] >>> >>> Eshell V5.8.1 (abort with ^G) >>> 1> c(test_ssl). >>> {ok,test_ssl} >>> 2> test_ssl:test(). >>> >>> =ERROR REPORT==== 17-Sep-2010::02:07:25 === >>> SSL: certify_certificate: ./ssl_handshake.erl:502:Fatal error: handshake >>> failure >>> ** exception error: no match of right hand side value {error,esslconnect} >>> in function test_ssl:test/0 >>> 3> >>> >>> However, if I pick up another server, like www.cia.gov:443 or >>> www.facebook.com:443 for example, it succeeds (with exactly the same ssl >>> options passed to ssl:connect/3). >>> Also tested with R13B03 and R13B04 and got the same results (only >>> modified >>> value of option verify from verify_none to 0). >>> >>> The code to test this eventual bug is: >>> >>> -module(test_ssl). >>> -compile(export_all). >>> >>> -define(HOST, "couchdb.staging.one.ubuntu.com"). >>> % -define(HOST, "www.cia.gov"). >>> >>> test() -> >>> Body = iolist_to_binary([ >>> "GET / HTTP/1.1\r\n", >>> "Host: ", ?HOST, "\r\n", >>> "Accept: */*\r\n", >>> "Connection: close\r\n", "\r\n" >>> ]), >>> application:start(crypto), >>> application:start(public_key), >>> application:start(ssl), >>> Options = [ >>> {ssl_imp, new}, >>> binary, >>> {nodelay, true}, >>> {active, false}, >>> {verify, verify_none} >>> % {verify_fun, fun(_) -> true end}, >>> ], >>> {ok, S} = ssl:connect(?HOST, 443, Options), >>> ok = ssl:send(S, Body), >>> loop(S), >>> ssl:close(S). >>> >>> loop(S) -> >>> ssl:setopts(S, [{active, once}]), >>> receive >>> {ssl, S, Data} -> >>> io:format("received data: ~p~n", [Data]), >>> loop(S); >>> {ssl_closed, S} -> >>> io:format("socket closed", []); >>> {ssl_error, S, Error} -> >>> io:format("socket error: ~p", [Error]) >>> end. >>> >>> >>> cheers >>> >>> >>> >> >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> >> > > > -- > Filipe David Manana, > fdmanana@REDACTED, fdmanana@REDACTED > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From ingela@REDACTED Mon Sep 20 12:05:25 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 20 Sep 2010 12:05:25 +0200 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: <4C93249F.3040408@erix.ericsson.se> Message-ID: <4C9731E5.2000603@erix.ericsson.se> Hi! Filipe David Manana wrote: > Just a few more questions, > > 1) are the 'verify_fun' and 'cacertfile' options meant to be used > together or are they mutually exclusive? > They are by no means mutually exclusive, and can be used together. If you do not have a 'cacertfile' (or cacerts option) you will always get the path-validation error unknown_ca. (As you can not validate a CA that you do not know by other means than the certificate path sent to you.) If you do not specify a a verify fun, all path validation errors will be treated as failures and you will not get a connection. The verify fun is there to let the application decide if it wants to accept some path validation errors such as for instance unknown_ca. The verify fun is used in verify_peer-mode. In verify_none mode is a little bit different depending on if you are server or client. In verify_none mode the server will not request the client to send a certificate and hence there will be be no path-validation. The client will always receive a certificate and go through the path-validation. So we are still discussion on how "generous" verify_none for the client should be. > 2) Trying to do this on Ubuntu: > > {cacertfile, "/etc/ssl/certs/ca-certificates.crt"} > > That file, is a list o PEM encoded certificate: > > $ file /etc/ssl/certs/ca-certificates.crt > /etc/ssl/certs/ca-certificates.crt: PEM certificate > > However I get the following exception when I pass that option: > > ** exception error: no match of right hand side value {error,ecacertfile} > in function ssl_test:test/0 > > =ERROR REPORT==== 17-Sep-2010::18:33:04 === > SSL: 1056: error:{error, > {badmatch, > {error, > {asn1, > {'Type not compatible with table constraint', > {{badmatch,{error,{asn1,{wrong_tag,{5,16}}}}}, > [{'OTP-PUB-KEY','dec_Dss-Parms',2}, > {'OTP-PUB-KEY',dec_SignatureAlgorithm,2}, > {'OTP-PUB-KEY',dec_OTPTBSCertificate,2}, > {'OTP-PUB-KEY',dec_OTPCertificate,2}, > {'OTP-PUB-KEY',decode,2}, > {pubkey_cert_records,decode_cert,1}, > {public_key,pkix_decode_cert,2}, > {ssl_certificate_db,add_certs,3}]}}}}}} > /etc/ssl/certs/ca-certificates.crt > [{ssl_connection,init_certificates,2}, > {ssl_connection,ssl_init,2}, > {ssl_connection,init,1}, > {gen_fsm,init_it,6}, > {proc_lib,init_p_do_apply,3}] > > Is this a bug? The ssl man page mentions the file is in the PEM format. > The file contents can be looked at: > http://friendpaste.com/4lQn7yihrUa4fE2Vs4u7JS > I have not verified this yet, but I think this looks like a bug in public_key that I have been working on solving that has to do with that certs may inherit DSS-Params from their issuer. > 3) For the verify function, it receives {bad_cert, unknown_ca} when a > certificate is self-signed? I would like to distinguish between > unknown CAs and self-signed certificates (certificate signed by the > target host). > I think you have a point here we will look in to this. Regards Ingela Erlang/OTP- team - Ericsson AB From fdmanana@REDACTED Mon Sep 20 12:40:28 2010 From: fdmanana@REDACTED (Filipe David Manana) Date: Mon, 20 Sep 2010 11:40:28 +0100 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: <4C9731E5.2000603@erix.ericsson.se> References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> Message-ID: On Mon, Sep 20, 2010 at 11:05 AM, Ingela Anderton Andin < ingela@REDACTED> wrote: > Hi! > > 2) Trying to do this on Ubuntu: >> >> {cacertfile, "/etc/ssl/certs/ca-certificates.crt"} >> >> That file, is a list o PEM encoded certificate: >> >> $ file /etc/ssl/certs/ca-certificates.crt >> /etc/ssl/certs/ca-certificates.crt: PEM certificate >> >> However I get the following exception when I pass that option: >> >> ** exception error: no match of right hand side value {error,ecacertfile} >> in function ssl_test:test/0 >> >> =ERROR REPORT==== 17-Sep-2010::18:33:04 === >> SSL: 1056: error:{error, >> {badmatch, >> {error, >> {asn1, >> {'Type not compatible with table constraint', >> {{badmatch,{error,{asn1,{wrong_tag,{5,16}}}}}, >> [{'OTP-PUB-KEY','dec_Dss-Parms',2}, >> {'OTP-PUB-KEY',dec_SignatureAlgorithm,2}, >> {'OTP-PUB-KEY',dec_OTPTBSCertificate,2}, >> {'OTP-PUB-KEY',dec_OTPCertificate,2}, >> {'OTP-PUB-KEY',decode,2}, >> {pubkey_cert_records,decode_cert,1}, >> {public_key,pkix_decode_cert,2}, >> {ssl_certificate_db,add_certs,3}]}}}}}} >> /etc/ssl/certs/ca-certificates.crt >> [{ssl_connection,init_certificates,2}, >> {ssl_connection,ssl_init,2}, >> {ssl_connection,init,1}, >> {gen_fsm,init_it,6}, >> {proc_lib,init_p_do_apply,3}] >> >> Is this a bug? The ssl man page mentions the file is in the PEM format. >> The file contents can be looked at: >> http://friendpaste.com/4lQn7yihrUa4fE2Vs4u7JS >> >> I have not verified this yet, but I think this looks like a bug in > public_key that I have been working on solving that has to do with that > certs may inherit DSS-Params from their issuer. The weird thing is that I can use this certificates file with the old ssl implementation (default on R13 and R12 releases) on R13B03 and R13B04 at least. So I definitely consider this a regression :( > > > 3) For the verify function, it receives {bad_cert, unknown_ca} when a >> certificate is self-signed? I would like to distinguish between unknown CAs >> and self-signed certificates (certificate signed by the target host). >> >> I think you have a point here we will look in to this. I think this would be very useful - to distinguish between an unknown CA (not listed in the trusted certificates file) and a certificate that was self-signed by the server. Thanks for all the answers and for looking into this. best regards, > > Regards Ingela Erlang/OTP- team - Ericsson AB > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From fdmanana@REDACTED Mon Sep 20 12:44:46 2010 From: fdmanana@REDACTED (Filipe David Manana) Date: Mon, 20 Sep 2010 11:44:46 +0100 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> Message-ID: Another thing to point, is that in my code (actually CouchDB), using the old ssl implementation I sometimes get the following exception thrown from the ssl module: [Thu, 16 Sep 2010 00:10:34 GMT] [error] [<0.604.0>] ** Generic server <0.604.0> terminating ** Last message in was {tcp,#Port<0.2288>, <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>} ** When Server state == {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false, [{mode,binary}, {nodelay,true}, {active,once}, {packet,0}, {ip,{0,0,0,0}}, {verify,0}, {depth,1}], {sslsocket,11,<0.604.0>}, #Port<0.2288>,nil,open,false,false} With the new ssl implementation I don't get this exception anymore. On the other hand, I have that issue of not being able to use the PEM certificates file (cacertfile option), therefore being forced to not use certificate validation :( cheers On Mon, Sep 20, 2010 at 11:40 AM, Filipe David Manana wrote: > > On Mon, Sep 20, 2010 at 11:05 AM, Ingela Anderton Andin < ingela@REDACTED> wrote: >> >> Hi! >> >>> 2) Trying to do this on Ubuntu: >>> >>> {cacertfile, "/etc/ssl/certs/ca-certificates.crt"} >>> >>> That file, is a list o PEM encoded certificate: >>> >>> $ file /etc/ssl/certs/ca-certificates.crt >>> /etc/ssl/certs/ca-certificates.crt: PEM certificate >>> >>> However I get the following exception when I pass that option: >>> >>> ** exception error: no match of right hand side value {error,ecacertfile} >>> in function ssl_test:test/0 >>> >>> =ERROR REPORT==== 17-Sep-2010::18:33:04 === >>> SSL: 1056: error:{error, >>> {badmatch, >>> {error, >>> {asn1, >>> {'Type not compatible with table constraint', >>> {{badmatch,{error,{asn1,{wrong_tag,{5,16}}}}}, >>> [{'OTP-PUB-KEY','dec_Dss-Parms',2}, >>> {'OTP-PUB-KEY',dec_SignatureAlgorithm,2}, >>> {'OTP-PUB-KEY',dec_OTPTBSCertificate,2}, >>> {'OTP-PUB-KEY',dec_OTPCertificate,2}, >>> {'OTP-PUB-KEY',decode,2}, >>> {pubkey_cert_records,decode_cert,1}, >>> {public_key,pkix_decode_cert,2}, >>> {ssl_certificate_db,add_certs,3}]}}}}}} /etc/ssl/certs/ca-certificates.crt >>> [{ssl_connection,init_certificates,2}, >>> {ssl_connection,ssl_init,2}, >>> {ssl_connection,init,1}, >>> {gen_fsm,init_it,6}, >>> {proc_lib,init_p_do_apply,3}] >>> >>> Is this a bug? The ssl man page mentions the file is in the PEM format. >>> The file contents can be looked at: http://friendpaste.com/4lQn7yihrUa4fE2Vs4u7JS >>> >> I have not verified this yet, but I think this looks like a bug in public_key that I have been working on solving that has to do with that >> certs may inherit DSS-Params from their issuer. > > The weird thing is that I can use this certificates file with the old ssl implementation (default on R13 and R12 releases) on R13B03 and R13B04 at least. > So I definitely consider this a regression :( > >> >> >>> 3) For the verify function, it receives {bad_cert, unknown_ca} when a certificate is self-signed? I would like to distinguish between unknown CAs and self-signed certificates (certificate signed by the target host). >>> >> I think you have a point here we will look in to this. > > I think this would be very useful - to distinguish between an unknown CA (not listed in the trusted certificates file) and a certificate that was self-signed by the server. > > > Thanks for all the answers and for looking into this. > > best regards, > >> >> >> Regards Ingela Erlang/OTP- team - Ericsson AB >> >> >> >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> > > > > -- > Filipe David Manana, > fdmanana@REDACTED, fdmanana@REDACTED > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From ingela@REDACTED Mon Sep 20 15:47:28 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 20 Sep 2010 15:47:28 +0200 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> Message-ID: <4C9765F0.7090801@erix.ericsson.se> Hi! [...] > > > {proc_lib,init_p_do_apply,3}] > > Is this a bug? The ssl man page mentions the file is in the > PEM format. > The file contents can be looked at: > http://friendpaste.com/4lQn7yihrUa4fE2Vs4u7JS > > I have not verified this yet, but I think this looks like a bug in > public_key that I have been working on solving that has to do with > that > certs may inherit DSS-Params from their issuer. > > > > The weird thing is that I can use this certificates file with the old > ssl implementation (default on R13 and R12 releases) on R13B03 and > R13B04 at least. > So I definitely consider this a regression :( Well the thing is that the old ssl-implementation only is an erlang-glue that leaves the most things up to the underlaying openssl implementation, but the new ssl only uses openssl crypto library and takes care the ssl protocol fsm-machinery and certificate handling on its own. This makes many things much easier to implement and removes the bottleneck enforced by the glue, and also lessens the required resource allocation. Of course this may cause new bugs occasionally and we fix them as fast as we can. If you want to try out the latest changes to fix the DSS-Params bug you can get the branch ia/ssl-asn1-spec-dss-params at my github account git@REDACTED:IngelaAndin/otp.git Regards Ingela Erlang/OTP team - Ericsson AB From nick@REDACTED Mon Sep 20 15:52:16 2010 From: nick@REDACTED (Niclas Eklund) Date: Mon, 20 Sep 2010 15:52:16 +0200 (CEST) Subject: [erlang-bugs] SSH problem in R14B In-Reply-To: References: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com> Message-ID: Hi! It seems like that the (deprecated) function public_key:pem_to_der/1 doesn't return the same thing as in R14A. As a temporary fix, you can change that function from: pem_to_der(CertSource) -> {ok, Bin} = file:read_file(CertSource), pubkey_pem:decode(Bin). to: pem_to_der(CertSource) -> {ok, Bin} = file:read_file(CertSource), {ok, pubkey_pem:decode(Bin)}. Then it should work. Or you can wait until a fix has been pushed. Best regards, Niclas @ Erlang/OTP On Thu, 16 Sep 2010, Maxim Treskin wrote: > Yes, have the same on Gentoo Linux amd64 > > On 16 September 2010 04:37, Gene Diveglia wrote: > >> >> Hi, it appears something has broken with SSH key exchange in R14B. None of >> my ssh based CLI are working in R14B, but were previously working in R14A >> immediately prior to upgrading. I can replicate the problem easily using >> [otp_src]/lib/ssh/examples/ssh_sample_cli.erl. This sample program works >> with R14A under OS X 10.6.4 x86, but will fail if run under R14B. The ssh >> client used in both cases was also on OS X 10.6.4 and was used with defaults >> other than the port number. Standard ssh host key files which are >> functional under the OS were used in both cases. I also tried a set of host >> key files generated with a different version of ssh-keygen under linux. The >> error report under R14B follows. >> >> Kind regards, >> >> -Gene >> >> =ERROR REPORT==== 15-Sep-2010::17:18:48 === >> ** State machine <0.55.0> terminating >> ** Last message in was {tcp,#Port<0.1003>, >> >> <<0,0,0,140,6,30,0,0,0,128,65,149,33,196,247,233, >> 21,88,218,104,244,10,153,132,125,40,71,44,131, >> >> 253,22,245,12,59,92,79,134,177,95,51,154,41,176, >> >> 243,232,208,168,184,12,181,124,38,62,214,81,115, >> >> 50,11,63,233,1,35,154,219,53,185,15,122,237,207, >> >> 92,254,52,163,183,160,234,190,135,187,237,54,76, >> 129,219,210,144,186,203,125,92,60,144,43,145, >> >> 252,215,173,236,140,234,156,165,21,133,116,117, >> >> 100,130,233,22,62,184,117,253,60,161,185,80,36, >> 18,166,97,155,71,133,192,82,143,61,176,78,177, >> 99,138,116,239,183,0,0,0,0,0,0>>} >> ** When State == key_exchange >> ** Data == {state,tcp,gen_tcp,tcp_closed, >> {ssh,server, >> {undefined,{{0,0,0,0,0,65535,32512,1},61612}}, >> {2,0}, >> {2,0}, >> "SSH-2.0-OpenSSH_5.2","SSH-2.0-Erlang", >> >> <<20,12,57,149,244,18,127,223,192,251,128,85,91,196, >> >> 128,29,110,0,0,0,126,100,105,102,102,105,101,45,104, >> 101,108,108,109,97,110,45,103,114,111,117,112,45, >> >> 101,120,99,104,97,110,103,101,45,115,104,97,50,53, >> 54,44,100,105,102,102,105,101,45,104,101,108,108, >> >> 109,97,110,45,103,114,111,117,112,45,101,120,99,104, >> >> 97,110,103,101,45,115,104,97,49,44,100,105,102,102, >> 105,101,45,104,101,108,108,109,97,110,45,103,114, >> >> 111,117,112,49,52,45,115,104,97,49,44,100,105,102, >> 102,105,101,45,104,101,108,108,109,97,110,45,103, >> 114,111,117,112,49,45,115,104,97,49,0,0,0,15,115, >> >> 115,104,45,114,115,97,44,115,115,104,45,100,115,115, >> >> 0,0,0,157,97,101,115,49,50,56,45,99,116,114,44,97, >> >> 101,115,49,57,50,45,99,116,114,44,97,101,115,50,53, >> >> 54,45,99,116,114,44,97,114,99,102,111,117,114,50,53, >> >> 54,44,97,114,99,102,111,117,114,49,50,56,44,97,101, >> >> 115,49,50,56,45,99,98,99,44,51,100,101,115,45,99,98, >> >> 99,44,98,108,111,119,102,105,115,104,45,99,98,99,44, >> >> 99,97,115,116,49,50,56,45,99,98,99,44,97,101,115,49, >> >> 57,50,45,99,98,99,44,97,101,115,50,53,54,45,99,98, >> >> 99,44,97,114,99,102,111,117,114,44,114,105,106,110, >> 100,97,101,108,45,99,98,99,64,108,121,115,97,116, >> >> 111,114,46,108,105,117,46,115,101,0,0,0,157,97,101, >> >> 115,49,50,56,45,99,116,114,44,97,101,115,49,57,50, >> >> 45,99,116,114,44,97,101,115,50,53,54,45,99,116,114, >> >> 44,97,114,99,102,111,117,114,50,53,54,44,97,114,99, >> >> 102,111,117,114,49,50,56,44,97,101,115,49,50,56,45, >> 99,98,99,44,51,100,101,115,45,99,98,99,44,98,108, >> 111,119,102,105,115,104,45,99,98,99,44,99,97,115, >> >> 116,49,50,56,45,99,98,99,44,97,101,115,49,57,50,45, >> >> 99,98,99,44,97,101,115,50,53,54,45,99,98,99,44,97, >> 114,99,102,111,117,114,44,114,105,106,110,100,97, >> >> 101,108,45,99,98,99,64,108,121,115,97,116,111,114, >> >> 46,108,105,117,46,115,101,0,0,0,105,104,109,97,99, >> >> 45,109,100,53,44,104,109,97,99,45,115,104,97,49,44, >> >> 117,109,97,99,45,54,52,64,111,112,101,110,115,115, >> >> 104,46,99,111,109,44,104,109,97,99,45,114,105,112, >> 101,109,100,49,54,48,44,104,109,97,99,45,114,105, >> >> 112,101,109,100,49,54,48,64,111,112,101,110,115,115, >> >> 104,46,99,111,109,44,104,109,97,99,45,115,104,97,49, >> >> 45,57,54,44,104,109,97,99,45,109,100,53,45,57,54,0, >> >> 0,0,105,104,109,97,99,45,109,100,53,44,104,109,97, >> 99,45,115,104,97,49,44,117,109,97,99,45,54,52,64, >> 111,112,101,110,115,115,104,46,99,111,109,44,104, >> 109,97,99,45,114,105,112,101,109,100,49,54,48,44, >> >> 104,109,97,99,45,114,105,112,101,109,100,49,54,48, >> >> 64,111,112,101,110,115,115,104,46,99,111,109,44,104, >> >> 109,97,99,45,115,104,97,49,45,57,54,44,104,109,97, >> >> 99,45,109,100,53,45,57,54,0,0,0,26,110,111,110,101, >> >> 44,122,108,105,98,64,111,112,101,110,115,115,104,46, >> >> 99,111,109,44,122,108,105,98,0,0,0,26,110,111,110, >> 101,44,122,108,105,98,64,111,112,101,110,115,115, >> >> 104,46,99,111,109,44,122,108,105,98,0,0,0,0,0,0,0,0, >> 0,0,0,0,0>>, >> >> <<20,38,144,242,6,169,190,51,74,102,5,149,16,239,7,65, >> >> 57,0,0,0,26,100,105,102,102,105,101,45,104,101,108, >> >> 108,109,97,110,45,103,114,111,117,112,49,45,115,104, >> >> 97,49,0,0,0,7,115,115,104,45,100,115,115,0,0,0,19, >> >> 97,101,115,49,50,56,45,99,98,99,44,51,100,101,115, >> >> 45,99,98,99,0,0,0,19,97,101,115,49,50,56,45,99,98, >> >> 99,44,51,100,101,115,45,99,98,99,0,0,0,9,104,109,97, >> 99,45,115,104,97,49,0,0,0,9,104,109,97,99,45,115, >> >> 104,97,49,0,0,0,9,110,111,110,101,44,122,108,105,98, >> >> 0,0,0,9,110,111,110,101,44,122,108,105,98,0,0,0,0,0, >> 0,0,0,0,0,0,0,0>>, >> {alg,'diffie-hellman-group1-sha1','ssh-dss', >> 'hmac-sha1','hmac-sha1','aes128-cbc', >> 'aes128-cbc',none,none,none,none}, >> >> undefined,undefined,ssh_file,ssh_io,none,undefined,0, >> none,undefined,0,none,undefined,8,undefined,none, >> >> undefined,8,undefined,none,undefined,none,undefined, >> none,none,true,infinity,undefined,undefined, >> undefined, >> [{address,"ims"}, >> {port,2223}, >> {system_dir,"/Users/gene/erl_ssh"}, >> {shell,#Fun}, >> {role,server}], >> 1,1,undefined,undefined,undefined,undefined, >> >> undefined,"publickey,keyboard_interactive,password", >> undefined,undefined}, >> #Port<0.1003>,<<>>,<<>>,undefined, >> {ssh_msg_kexinit, >> <<127,229,163,177,131,154,163,20,128,32,226,34,154, >> 235,187,170>>, >> ["diffie-hellman-group1-sha1"], >> ["ssh-dss"], >> ["aes128-cbc","3des-cbc"], >> ["aes128-cbc","3des-cbc"], >> ["hmac-sha1"], >> ["hmac-sha1"], >> ["none","zlib"], >> ["none","zlib"], >> [],[],false,0}, >> false,<0.54.0>,undefined,undefined,undefined, >> [{address,"ims"}, >> {port,2223}, >> {system_dir,"/Users/gene/erl_ssh"}, >> {shell,#Fun}, >> {role,server}]} >> ** Reason for termination = >> ** >> {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, >> >> 87,111,15,213,167,162,93,159,122,170,251,197,236, >> 195,42,174,179,117,37,219,193,70,162,69,63,82, >> >> 132,149,99,206,90,198,153,34,211,176,14,89,142, >> >> 220,203,9,122,34,99,12,156,119,19,117,186,2,233, >> >> 151,22,31,96,153,210,219,121,225,207,231,39,246, >> >> 64,108,176,211,77,252,98,34,16,210,73,17,189,187, >> >> 193,111,191,143,115,49,60,159,218,245,67,241,2, >> 130,232,145,217,10,236,86,139,125,238,252,102, >> >> 246,213,110,249,125,80,182,210,55,229,163,214,91, >> >> 112,60,117,209,220,205,2,21,0,159,83,129,175,245, >> 131,186,139,165,18,35,133,43,148,124,202,31,9, >> >> 142,189,2,129,128,107,72,221,121,89,226,22,151, >> >> 35,105,202,173,197,168,100,60,58,6,23,223,9,121, >> >> 175,53,248,135,5,120,183,100,107,135,102,219,116, >> >> 63,213,17,149,118,142,19,143,204,168,236,49,165, >> >> 1,136,195,111,248,199,182,253,234,46,173,28,30, >> >> 114,240,8,77,176,107,184,41,108,183,172,165,202, >> 3,90,166,69,76,202,187,58,133,192,38,1,38,110, >> >> 212,36,18,35,149,58,218,69,134,143,42,1,174,19, >> >> 233,236,61,165,187,157,254,168,163,243,248,227, >> >> 110,122,213,72,107,214,220,212,99,245,106,120,91, >> >> 131,2,129,128,113,214,224,173,14,157,34,113,59, >> >> 116,57,129,233,210,114,12,213,159,133,106,34,130, >> >> 102,199,157,241,226,84,186,245,237,230,106,6,231, >> >> 231,140,208,106,53,74,56,77,48,92,112,47,91,236, >> 135,107,16,8,93,241,130,5,118,126,197,127,233, >> >> 238,199,226,7,79,225,193,139,174,87,11,168,190, >> >> 220,127,150,135,210,198,209,242,104,166,143,236, >> >> 18,125,22,64,26,53,139,45,219,45,144,236,245,193, >> >> 127,152,100,103,179,152,156,208,18,94,96,227,44, >> >> 151,136,194,77,114,12,70,223,143,194,196,204,101, >> >> 184,2,20,43,222,65,115,20,238,35,218,102,176,95, >> 196,101,68,47,163,229,153,49,118>>, >> not_encrypted}]} >> >> =ERROR REPORT==== 15-Sep-2010::17:18:48 === >> ** Generic server <0.52.0> terminating >> ** Last message in was {'EXIT',<0.55.0>, >> {error, >> [{'DSAPrivateKey', >> >> <<48,130,1,186,2,1,0,2,129,129,0,170,223, >> >> 146,206,87,111,15,213,167,162,93,159,122, >> 170,251,197,236,195,42,174,179,117,37, >> >> 219,193,70,162,69,63,82,132,149,99,206, >> >> 90,198,153,34,211,176,14,89,142,220,203, >> >> 9,122,34,99,12,156,119,19,117,186,2,233, >> >> 151,22,31,96,153,210,219,121,225,207,231, >> 39,246,64,108,176,211,77,252,98,34,16, >> >> 210,73,17,189,187,193,111,191,143,115,49, >> >> 60,159,218,245,67,241,2,130,232,145,217, >> 10,236,86,139,125,238,252,102,246,213, >> >> 110,249,125,80,182,210,55,229,163,214,91, >> >> 112,60,117,209,220,205,2,21,0,159,83,129, >> >> 175,245,131,186,139,165,18,35,133,43,148, >> 124,202,31,9,142,189,2,129,128,107,72, >> >> 221,121,89,226,22,151,35,105,202,173,197, >> >> 168,100,60,58,6,23,223,9,121,175,53,248, >> >> 135,5,120,183,100,107,135,102,219,116,63, >> >> 213,17,149,118,142,19,143,204,168,236,49, >> >> 165,1,136,195,111,248,199,182,253,234,46, >> 173,28,30,114,240,8,77,176,107,184,41, >> >> 108,183,172,165,202,3,90,166,69,76,202, >> >> 187,58,133,192,38,1,38,110,212,36,18,35, >> 149,58,218,69,134,143,42,1,174,19,233, >> >> 236,61,165,187,157,254,168,163,243,248, >> 227,110,122,213,72,107,214,220,212,99, >> >> 245,106,120,91,131,2,129,128,113,214,224, >> >> 173,14,157,34,113,59,116,57,129,233,210, >> 114,12,213,159,133,106,34,130,102,199, >> >> 157,241,226,84,186,245,237,230,106,6,231, >> >> 231,140,208,106,53,74,56,77,48,92,112,47, >> >> 91,236,135,107,16,8,93,241,130,5,118,126, >> >> 197,127,233,238,199,226,7,79,225,193,139, >> 174,87,11,168,190,220,127,150,135,210, >> >> 198,209,242,104,166,143,236,18,125,22,64, >> >> 26,53,139,45,219,45,144,236,245,193,127, >> >> 152,100,103,179,152,156,208,18,94,96,227, >> >> 44,151,136,194,77,114,12,70,223,143,194, >> 196,204,101,184,2,20,43,222,65,115,20, >> >> 238,35,218,102,176,95,196,101,68,47,163, >> 229,153,49,118>>, >> not_encrypted}]}} >> ** When Server state == {state,server,<0.54.0>,<0.55.0>,undefined} >> ** Reason for termination == >> ** >> {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, >> >> 87,111,15,213,167,162,93,159,122,170,251,197,236, >> 195,42,174,179,117,37,219,193,70,162,69,63,82, >> >> 132,149,99,206,90,198,153,34,211,176,14,89,142, >> >> 220,203,9,122,34,99,12,156,119,19,117,186,2,233, >> >> 151,22,31,96,153,210,219,121,225,207,231,39,246, >> >> 64,108,176,211,77,252,98,34,16,210,73,17,189,187, >> >> 193,111,191,143,115,49,60,159,218,245,67,241,2, >> 130,232,145,217,10,236,86,139,125,238,252,102, >> >> 246,213,110,249,125,80,182,210,55,229,163,214,91, >> >> 112,60,117,209,220,205,2,21,0,159,83,129,175,245, >> 131,186,139,165,18,35,133,43,148,124,202,31,9, >> >> 142,189,2,129,128,107,72,221,121,89,226,22,151, >> >> 35,105,202,173,197,168,100,60,58,6,23,223,9,121, >> >> 175,53,248,135,5,120,183,100,107,135,102,219,116, >> >> 63,213,17,149,118,142,19,143,204,168,236,49,165, >> >> 1,136,195,111,248,199,182,253,234,46,173,28,30, >> >> 114,240,8,77,176,107,184,41,108,183,172,165,202, >> 3,90,166,69,76,202,187,58,133,192,38,1,38,110, >> >> 212,36,18,35,149,58,218,69,134,143,42,1,174,19, >> >> 233,236,61,165,187,157,254,168,163,243,248,227, >> >> 110,122,213,72,107,214,220,212,99,245,106,120,91, >> >> 131,2,129,128,113,214,224,173,14,157,34,113,59, >> >> 116,57,129,233,210,114,12,213,159,133,106,34,130, >> >> 102,199,157,241,226,84,186,245,237,230,106,6,231, >> >> 231,140,208,106,53,74,56,77,48,92,112,47,91,236, >> 135,107,16,8,93,241,130,5,118,126,197,127,233, >> >> 238,199,226,7,79,225,193,139,174,87,11,168,190, >> >> 220,127,150,135,210,198,209,242,104,166,143,236, >> >> 18,125,22,64,26,53,139,45,219,45,144,236,245,193, >> >> 127,152,100,103,179,152,156,208,18,94,96,227,44, >> >> 151,136,194,77,114,12,70,223,143,194,196,204,101, >> >> 184,2,20,43,222,65,115,20,238,35,218,102,176,95, >> 196,101,68,47,163,229,153,49,118>>, >> not_encrypted}]} >> >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> >> > > > -- > Maxim Treskin > From gdiveglia@REDACTED Mon Sep 20 16:16:49 2010 From: gdiveglia@REDACTED (Gene Diveglia) Date: Mon, 20 Sep 2010 10:16:49 -0400 Subject: [erlang-bugs] SSH problem in R14B In-Reply-To: References: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com> Message-ID: <0F93A380-1AB7-4CE3-B0FB-08A7FDFBA360@mac.com> Thanks Niclas! That change resolved the problem. Kind regards, -Gene On Sep 20, 2010, at 9:52 AM, Niclas Eklund wrote: > > Hi! > > It seems like that the (deprecated) function public_key:pem_to_der/1 doesn't return the same thing as in R14A. As a temporary fix, you can change that function from: > > pem_to_der(CertSource) -> > {ok, Bin} = file:read_file(CertSource), > pubkey_pem:decode(Bin). > > to: > > pem_to_der(CertSource) -> > {ok, Bin} = file:read_file(CertSource), > {ok, pubkey_pem:decode(Bin)}. > > Then it should work. Or you can wait until a fix has been pushed. > > Best regards, > > Niclas @ Erlang/OTP > > On Thu, 16 Sep 2010, Maxim Treskin wrote: > >> Yes, have the same on Gentoo Linux amd64 >> >> On 16 September 2010 04:37, Gene Diveglia wrote: >> >>> >>> Hi, it appears something has broken with SSH key exchange in R14B. None of >>> my ssh based CLI are working in R14B, but were previously working in R14A >>> immediately prior to upgrading. I can replicate the problem easily using >>> [otp_src]/lib/ssh/examples/ssh_sample_cli.erl. This sample program works >>> with R14A under OS X 10.6.4 x86, but will fail if run under R14B. The ssh >>> client used in both cases was also on OS X 10.6.4 and was used with defaults >>> other than the port number. Standard ssh host key files which are >>> functional under the OS were used in both cases. I also tried a set of host >>> key files generated with a different version of ssh-keygen under linux. The >>> error report under R14B follows. >>> >>> Kind regards, >>> >>> -Gene >>> >>> =ERROR REPORT==== 15-Sep-2010::17:18:48 === >>> ** State machine <0.55.0> terminating >>> ** Last message in was {tcp,#Port<0.1003>, >>> >>> <<0,0,0,140,6,30,0,0,0,128,65,149,33,196,247,233, >>> 21,88,218,104,244,10,153,132,125,40,71,44,131, >>> >>> 253,22,245,12,59,92,79,134,177,95,51,154,41,176, >>> >>> 243,232,208,168,184,12,181,124,38,62,214,81,115, >>> >>> 50,11,63,233,1,35,154,219,53,185,15,122,237,207, >>> >>> 92,254,52,163,183,160,234,190,135,187,237,54,76, >>> 129,219,210,144,186,203,125,92,60,144,43,145, >>> >>> 252,215,173,236,140,234,156,165,21,133,116,117, >>> >>> 100,130,233,22,62,184,117,253,60,161,185,80,36, >>> 18,166,97,155,71,133,192,82,143,61,176,78,177, >>> 99,138,116,239,183,0,0,0,0,0,0>>} >>> ** When State == key_exchange >>> ** Data == {state,tcp,gen_tcp,tcp_closed, >>> {ssh,server, >>> {undefined,{{0,0,0,0,0,65535,32512,1},61612}}, >>> {2,0}, >>> {2,0}, >>> "SSH-2.0-OpenSSH_5.2","SSH-2.0-Erlang", >>> >>> <<20,12,57,149,244,18,127,223,192,251,128,85,91,196, >>> >>> 128,29,110,0,0,0,126,100,105,102,102,105,101,45,104, >>> 101,108,108,109,97,110,45,103,114,111,117,112,45, >>> >>> 101,120,99,104,97,110,103,101,45,115,104,97,50,53, >>> 54,44,100,105,102,102,105,101,45,104,101,108,108, >>> >>> 109,97,110,45,103,114,111,117,112,45,101,120,99,104, >>> >>> 97,110,103,101,45,115,104,97,49,44,100,105,102,102, >>> 105,101,45,104,101,108,108,109,97,110,45,103,114, >>> >>> 111,117,112,49,52,45,115,104,97,49,44,100,105,102, >>> 102,105,101,45,104,101,108,108,109,97,110,45,103, >>> 114,111,117,112,49,45,115,104,97,49,0,0,0,15,115, >>> >>> 115,104,45,114,115,97,44,115,115,104,45,100,115,115, >>> >>> 0,0,0,157,97,101,115,49,50,56,45,99,116,114,44,97, >>> >>> 101,115,49,57,50,45,99,116,114,44,97,101,115,50,53, >>> >>> 54,45,99,116,114,44,97,114,99,102,111,117,114,50,53, >>> >>> 54,44,97,114,99,102,111,117,114,49,50,56,44,97,101, >>> >>> 115,49,50,56,45,99,98,99,44,51,100,101,115,45,99,98, >>> >>> 99,44,98,108,111,119,102,105,115,104,45,99,98,99,44, >>> >>> 99,97,115,116,49,50,56,45,99,98,99,44,97,101,115,49, >>> >>> 57,50,45,99,98,99,44,97,101,115,50,53,54,45,99,98, >>> >>> 99,44,97,114,99,102,111,117,114,44,114,105,106,110, >>> 100,97,101,108,45,99,98,99,64,108,121,115,97,116, >>> >>> 111,114,46,108,105,117,46,115,101,0,0,0,157,97,101, >>> >>> 115,49,50,56,45,99,116,114,44,97,101,115,49,57,50, >>> >>> 45,99,116,114,44,97,101,115,50,53,54,45,99,116,114, >>> >>> 44,97,114,99,102,111,117,114,50,53,54,44,97,114,99, >>> >>> 102,111,117,114,49,50,56,44,97,101,115,49,50,56,45, >>> 99,98,99,44,51,100,101,115,45,99,98,99,44,98,108, >>> 111,119,102,105,115,104,45,99,98,99,44,99,97,115, >>> >>> 116,49,50,56,45,99,98,99,44,97,101,115,49,57,50,45, >>> >>> 99,98,99,44,97,101,115,50,53,54,45,99,98,99,44,97, >>> 114,99,102,111,117,114,44,114,105,106,110,100,97, >>> >>> 101,108,45,99,98,99,64,108,121,115,97,116,111,114, >>> >>> 46,108,105,117,46,115,101,0,0,0,105,104,109,97,99, >>> >>> 45,109,100,53,44,104,109,97,99,45,115,104,97,49,44, >>> >>> 117,109,97,99,45,54,52,64,111,112,101,110,115,115, >>> >>> 104,46,99,111,109,44,104,109,97,99,45,114,105,112, >>> 101,109,100,49,54,48,44,104,109,97,99,45,114,105, >>> >>> 112,101,109,100,49,54,48,64,111,112,101,110,115,115, >>> >>> 104,46,99,111,109,44,104,109,97,99,45,115,104,97,49, >>> >>> 45,57,54,44,104,109,97,99,45,109,100,53,45,57,54,0, >>> >>> 0,0,105,104,109,97,99,45,109,100,53,44,104,109,97, >>> 99,45,115,104,97,49,44,117,109,97,99,45,54,52,64, >>> 111,112,101,110,115,115,104,46,99,111,109,44,104, >>> 109,97,99,45,114,105,112,101,109,100,49,54,48,44, >>> >>> 104,109,97,99,45,114,105,112,101,109,100,49,54,48, >>> >>> 64,111,112,101,110,115,115,104,46,99,111,109,44,104, >>> >>> 109,97,99,45,115,104,97,49,45,57,54,44,104,109,97, >>> >>> 99,45,109,100,53,45,57,54,0,0,0,26,110,111,110,101, >>> >>> 44,122,108,105,98,64,111,112,101,110,115,115,104,46, >>> >>> 99,111,109,44,122,108,105,98,0,0,0,26,110,111,110, >>> 101,44,122,108,105,98,64,111,112,101,110,115,115, >>> >>> 104,46,99,111,109,44,122,108,105,98,0,0,0,0,0,0,0,0, >>> 0,0,0,0,0>>, >>> >>> <<20,38,144,242,6,169,190,51,74,102,5,149,16,239,7,65, >>> >>> 57,0,0,0,26,100,105,102,102,105,101,45,104,101,108, >>> >>> 108,109,97,110,45,103,114,111,117,112,49,45,115,104, >>> >>> 97,49,0,0,0,7,115,115,104,45,100,115,115,0,0,0,19, >>> >>> 97,101,115,49,50,56,45,99,98,99,44,51,100,101,115, >>> >>> 45,99,98,99,0,0,0,19,97,101,115,49,50,56,45,99,98, >>> >>> 99,44,51,100,101,115,45,99,98,99,0,0,0,9,104,109,97, >>> 99,45,115,104,97,49,0,0,0,9,104,109,97,99,45,115, >>> >>> 104,97,49,0,0,0,9,110,111,110,101,44,122,108,105,98, >>> >>> 0,0,0,9,110,111,110,101,44,122,108,105,98,0,0,0,0,0, >>> 0,0,0,0,0,0,0,0>>, >>> {alg,'diffie-hellman-group1-sha1','ssh-dss', >>> 'hmac-sha1','hmac-sha1','aes128-cbc', >>> 'aes128-cbc',none,none,none,none}, >>> >>> undefined,undefined,ssh_file,ssh_io,none,undefined,0, >>> none,undefined,0,none,undefined,8,undefined,none, >>> >>> undefined,8,undefined,none,undefined,none,undefined, >>> none,none,true,infinity,undefined,undefined, >>> undefined, >>> [{address,"ims"}, >>> {port,2223}, >>> {system_dir,"/Users/gene/erl_ssh"}, >>> {shell,#Fun}, >>> {role,server}], >>> 1,1,undefined,undefined,undefined,undefined, >>> >>> undefined,"publickey,keyboard_interactive,password", >>> undefined,undefined}, >>> #Port<0.1003>,<<>>,<<>>,undefined, >>> {ssh_msg_kexinit, >>> <<127,229,163,177,131,154,163,20,128,32,226,34,154, >>> 235,187,170>>, >>> ["diffie-hellman-group1-sha1"], >>> ["ssh-dss"], >>> ["aes128-cbc","3des-cbc"], >>> ["aes128-cbc","3des-cbc"], >>> ["hmac-sha1"], >>> ["hmac-sha1"], >>> ["none","zlib"], >>> ["none","zlib"], >>> [],[],false,0}, >>> false,<0.54.0>,undefined,undefined,undefined, >>> [{address,"ims"}, >>> {port,2223}, >>> {system_dir,"/Users/gene/erl_ssh"}, >>> {shell,#Fun}, >>> {role,server}]} >>> ** Reason for termination = >>> ** >>> {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, >>> >>> 87,111,15,213,167,162,93,159,122,170,251,197,236, >>> 195,42,174,179,117,37,219,193,70,162,69,63,82, >>> >>> 132,149,99,206,90,198,153,34,211,176,14,89,142, >>> >>> 220,203,9,122,34,99,12,156,119,19,117,186,2,233, >>> >>> 151,22,31,96,153,210,219,121,225,207,231,39,246, >>> >>> 64,108,176,211,77,252,98,34,16,210,73,17,189,187, >>> >>> 193,111,191,143,115,49,60,159,218,245,67,241,2, >>> 130,232,145,217,10,236,86,139,125,238,252,102, >>> >>> 246,213,110,249,125,80,182,210,55,229,163,214,91, >>> >>> 112,60,117,209,220,205,2,21,0,159,83,129,175,245, >>> 131,186,139,165,18,35,133,43,148,124,202,31,9, >>> >>> 142,189,2,129,128,107,72,221,121,89,226,22,151, >>> >>> 35,105,202,173,197,168,100,60,58,6,23,223,9,121, >>> >>> 175,53,248,135,5,120,183,100,107,135,102,219,116, >>> >>> 63,213,17,149,118,142,19,143,204,168,236,49,165, >>> >>> 1,136,195,111,248,199,182,253,234,46,173,28,30, >>> >>> 114,240,8,77,176,107,184,41,108,183,172,165,202, >>> 3,90,166,69,76,202,187,58,133,192,38,1,38,110, >>> >>> 212,36,18,35,149,58,218,69,134,143,42,1,174,19, >>> >>> 233,236,61,165,187,157,254,168,163,243,248,227, >>> >>> 110,122,213,72,107,214,220,212,99,245,106,120,91, >>> >>> 131,2,129,128,113,214,224,173,14,157,34,113,59, >>> >>> 116,57,129,233,210,114,12,213,159,133,106,34,130, >>> >>> 102,199,157,241,226,84,186,245,237,230,106,6,231, >>> >>> 231,140,208,106,53,74,56,77,48,92,112,47,91,236, >>> 135,107,16,8,93,241,130,5,118,126,197,127,233, >>> >>> 238,199,226,7,79,225,193,139,174,87,11,168,190, >>> >>> 220,127,150,135,210,198,209,242,104,166,143,236, >>> >>> 18,125,22,64,26,53,139,45,219,45,144,236,245,193, >>> >>> 127,152,100,103,179,152,156,208,18,94,96,227,44, >>> >>> 151,136,194,77,114,12,70,223,143,194,196,204,101, >>> >>> 184,2,20,43,222,65,115,20,238,35,218,102,176,95, >>> 196,101,68,47,163,229,153,49,118>>, >>> not_encrypted}]} >>> >>> =ERROR REPORT==== 15-Sep-2010::17:18:48 === >>> ** Generic server <0.52.0> terminating >>> ** Last message in was {'EXIT',<0.55.0>, >>> {error, >>> [{'DSAPrivateKey', >>> >>> <<48,130,1,186,2,1,0,2,129,129,0,170,223, >>> >>> 146,206,87,111,15,213,167,162,93,159,122, >>> 170,251,197,236,195,42,174,179,117,37, >>> >>> 219,193,70,162,69,63,82,132,149,99,206, >>> >>> 90,198,153,34,211,176,14,89,142,220,203, >>> >>> 9,122,34,99,12,156,119,19,117,186,2,233, >>> >>> 151,22,31,96,153,210,219,121,225,207,231, >>> 39,246,64,108,176,211,77,252,98,34,16, >>> >>> 210,73,17,189,187,193,111,191,143,115,49, >>> >>> 60,159,218,245,67,241,2,130,232,145,217, >>> 10,236,86,139,125,238,252,102,246,213, >>> >>> 110,249,125,80,182,210,55,229,163,214,91, >>> >>> 112,60,117,209,220,205,2,21,0,159,83,129, >>> >>> 175,245,131,186,139,165,18,35,133,43,148, >>> 124,202,31,9,142,189,2,129,128,107,72, >>> >>> 221,121,89,226,22,151,35,105,202,173,197, >>> >>> 168,100,60,58,6,23,223,9,121,175,53,248, >>> >>> 135,5,120,183,100,107,135,102,219,116,63, >>> >>> 213,17,149,118,142,19,143,204,168,236,49, >>> >>> 165,1,136,195,111,248,199,182,253,234,46, >>> 173,28,30,114,240,8,77,176,107,184,41, >>> >>> 108,183,172,165,202,3,90,166,69,76,202, >>> >>> 187,58,133,192,38,1,38,110,212,36,18,35, >>> 149,58,218,69,134,143,42,1,174,19,233, >>> >>> 236,61,165,187,157,254,168,163,243,248, >>> 227,110,122,213,72,107,214,220,212,99, >>> >>> 245,106,120,91,131,2,129,128,113,214,224, >>> >>> 173,14,157,34,113,59,116,57,129,233,210, >>> 114,12,213,159,133,106,34,130,102,199, >>> >>> 157,241,226,84,186,245,237,230,106,6,231, >>> >>> 231,140,208,106,53,74,56,77,48,92,112,47, >>> >>> 91,236,135,107,16,8,93,241,130,5,118,126, >>> >>> 197,127,233,238,199,226,7,79,225,193,139, >>> 174,87,11,168,190,220,127,150,135,210, >>> >>> 198,209,242,104,166,143,236,18,125,22,64, >>> >>> 26,53,139,45,219,45,144,236,245,193,127, >>> >>> 152,100,103,179,152,156,208,18,94,96,227, >>> >>> 44,151,136,194,77,114,12,70,223,143,194, >>> 196,204,101,184,2,20,43,222,65,115,20, >>> >>> 238,35,218,102,176,95,196,101,68,47,163, >>> 229,153,49,118>>, >>> not_encrypted}]}} >>> ** When Server state == {state,server,<0.54.0>,<0.55.0>,undefined} >>> ** Reason for termination == >>> ** >>> {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, >>> >>> 87,111,15,213,167,162,93,159,122,170,251,197,236, >>> 195,42,174,179,117,37,219,193,70,162,69,63,82, >>> >>> 132,149,99,206,90,198,153,34,211,176,14,89,142, >>> >>> 220,203,9,122,34,99,12,156,119,19,117,186,2,233, >>> >>> 151,22,31,96,153,210,219,121,225,207,231,39,246, >>> >>> 64,108,176,211,77,252,98,34,16,210,73,17,189,187, >>> >>> 193,111,191,143,115,49,60,159,218,245,67,241,2, >>> 130,232,145,217,10,236,86,139,125,238,252,102, >>> >>> 246,213,110,249,125,80,182,210,55,229,163,214,91, >>> >>> 112,60,117,209,220,205,2,21,0,159,83,129,175,245, >>> 131,186,139,165,18,35,133,43,148,124,202,31,9, >>> >>> 142,189,2,129,128,107,72,221,121,89,226,22,151, >>> >>> 35,105,202,173,197,168,100,60,58,6,23,223,9,121, >>> >>> 175,53,248,135,5,120,183,100,107,135,102,219,116, >>> >>> 63,213,17,149,118,142,19,143,204,168,236,49,165, >>> >>> 1,136,195,111,248,199,182,253,234,46,173,28,30, >>> >>> 114,240,8,77,176,107,184,41,108,183,172,165,202, >>> 3,90,166,69,76,202,187,58,133,192,38,1,38,110, >>> >>> 212,36,18,35,149,58,218,69,134,143,42,1,174,19, >>> >>> 233,236,61,165,187,157,254,168,163,243,248,227, >>> >>> 110,122,213,72,107,214,220,212,99,245,106,120,91, >>> >>> 131,2,129,128,113,214,224,173,14,157,34,113,59, >>> >>> 116,57,129,233,210,114,12,213,159,133,106,34,130, >>> >>> 102,199,157,241,226,84,186,245,237,230,106,6,231, >>> >>> 231,140,208,106,53,74,56,77,48,92,112,47,91,236, >>> 135,107,16,8,93,241,130,5,118,126,197,127,233, >>> >>> 238,199,226,7,79,225,193,139,174,87,11,168,190, >>> >>> 220,127,150,135,210,198,209,242,104,166,143,236, >>> >>> 18,125,22,64,26,53,139,45,219,45,144,236,245,193, >>> >>> 127,152,100,103,179,152,156,208,18,94,96,227,44, >>> >>> 151,136,194,77,114,12,70,223,143,194,196,204,101, >>> >>> 184,2,20,43,222,65,115,20,238,35,218,102,176,95, >>> 196,101,68,47,163,229,153,49,118>>, >>> not_encrypted}]} >>> >>> >>> ________________________________________________________________ >>> erlang-bugs (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >>> >>> >> >> >> -- >> Maxim Treskin >> > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > From john.hughes@REDACTED Mon Sep 20 17:09:56 2010 From: john.hughes@REDACTED (John Hughes) Date: Mon, 20 Sep 2010 17:09:56 +0200 Subject: Two bugs in dets In-Reply-To: <0F93A380-1AB7-4CE3-B0FB-08A7FDFBA360@mac.com> References: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com> <0F93A380-1AB7-4CE3-B0FB-08A7FDFBA360@mac.com> Message-ID: I've been using dets as an example for some new QuickCheck features, and seem to have discovered a couple of race conditions. Firstly, insert_new is documented as returning a bool, but under certain circumstances it can return ok instead. This code prints ok every time on my machine (R14B under Windows): bug1() -> T = dets:open_file(dets_table,[{type,bag}]), spawn(fun()->dets:insert(T,[]) end), spawn(fun()->io:format("~p\n",[dets:insert_new(T,[])]) end). Both spawns are necessary to make this happen--otherwise the output is true, as it should be. Secondly, the following code causes a bug message to appear: bug3() -> file:delete(dets_table), T = dets:open_file(dets_table,[{type,set}]), spawn(fun() -> dets:delete(T,0) end), spawn(fun() -> dets:insert_new(T,{0,0}) end), ok. When I run this with DETS_DEBUG set, I see this output: 87> dets_bugs:bug3(). =ERROR REPORT==== 20-Sep-2010::16:54:35 === ** dets: Bug was found when accessing table dets_table, ** dets: operation was {delete_key,[0]} and reply was {'EXIT',{function_clause,[{dets_v9,eval_key1,[[{1,insert_new}],[],[],set,{0,0},[],[],0,[]]},{dets_v9,eval_key,9},{dets_v9,eval_slot,9},{dets_v9,eval_bucket_keys,8},{dets_v9,read_buckets,11},{dets,update_cache,2},{dets,stream_end,5},{dets,do_apply_op,4}]}}. ** dets: Stacktrace: [{dets,stream_end,5},{dets,do_apply_op,4},{proc_lib,init_p_do_apply,3}] ok I've seen the same behaviour for sets and bags, and when the delete is replaced by an insert (although that's a little harder to provoke). Sample output from a QuickCheck run that shows the latter case is below (but it looks like the same bug). I'm attaching the QuickCheck spec that found these race conditions also--I can provide the right version of QuickCheck to run it and a trial licence if desired. It just focusses on the subset of operations in these examples, and its pretty good at finding a variety of variations on the theme. 6> eqc:check(dets_eqc:prop_parallel(),eqc:counterexample()). =INFO REPORT==== 20-Sep-2010::17:01:59 === ** dets: (debug) using disk map for dets_table =INFO REPORT==== 20-Sep-2010::17:01:59 === ** dets: (debug) using disk map for dets_table =ERROR REPORT==== 20-Sep-2010::17:01:59 === ** dets: Bug was found when accessing table dets_table, ** dets: operation was {insert,[]} and reply was {'EXIT',{function_clause,[{dets_v9,eval_key1,[[{0,insert_new}],[],[],bag,{0,0},[],[],0,[]]},{dets_v9,eval_key,9},{dets_v9,eval_slot,9},{dets_v9,eval_bucket_keys,8},{dets_v9,read_buckets,11},{dets,update_cache,2},{dets,stream_end,5},{dets,do_apply_op,4}]}}. ** dets: Stacktrace: [{dets,stream_end,5},{dets,do_apply_op,4},{proc_lib,init_p_do_apply,3}] Failed! Reason: {'EXIT',{timeout,1000}} 100 {[{set,{var,1},{call,dets_eqc,open_file,[dets_table,[{type,bag}]]}}], [[{set,{var,17},{call,dets,insert_new,[{var,1},{0,0}]}}], [{set,{var,19},{call,dets,insert,[{var,1},[]]}}]]} false 7> =ERROR REPORT==== 20-Sep-2010::17:02:00 === Error in process <0.14925.0> with exit value: {badarg,[{dets,insert_new,[dets_table,{0,0}]},{eqc_run_parallel_commands,run_child,3}]} John -------------- next part -------------- A non-text attachment was scrubbed... Name: dets_eqc.erl Type: application/octet-stream Size: 4926 bytes Desc: not available URL: From ulf.wiger@REDACTED Mon Sep 20 17:54:29 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 20 Sep 2010 17:54:29 +0200 Subject: [erlang-bugs] Two bugs in dets In-Reply-To: References: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com> <0F93A380-1AB7-4CE3-B0FB-08A7FDFBA360@mac.com> Message-ID: <4C9783B5.4080408@erlang-solutions.com> I got the same thing when running your examples, but the code requires two minor corrections: dets:open_file/2 returns {ok, T}, not just T. BR, Ulf W On 20/09/2010 17:09, John Hughes wrote: > I've been using dets as an example for some new QuickCheck features, and > seem to have discovered a couple of race conditions. > > Firstly, insert_new is documented as returning a bool, but under certain > circumstances it can return ok instead. This code prints ok every time > on my machine (R14B under Windows): > > bug1() -> > T = dets:open_file(dets_table,[{type,bag}]), > spawn(fun()->dets:insert(T,[]) end), > spawn(fun()->io:format("~p\n",[dets:insert_new(T,[])]) end). > > Both spawns are necessary to make this happen--otherwise the output is > true, as it should be. > > Secondly, the following code causes a bug message to appear: > > bug3() -> > file:delete(dets_table), > T = dets:open_file(dets_table,[{type,set}]), > spawn(fun() -> dets:delete(T,0) end), > spawn(fun() -> dets:insert_new(T,{0,0}) end), > ok. > > When I run this with DETS_DEBUG set, I see this output: > > 87> dets_bugs:bug3(). > > =ERROR REPORT==== 20-Sep-2010::16:54:35 === > ** dets: Bug was found when accessing table dets_table, > ** dets: operation was {delete_key,[0]} and reply was > {'EXIT',{function_clause,[{dets_v9,eval_key1,[[{1,insert_new}],[],[],set,{0,0},[],[],0,[]]},{dets_v9,eval_key,9},{dets_v9,eval_slot,9},{dets_v9,eval_bucket_keys,8},{dets_v9,read_buckets,11},{dets,update_cache,2},{dets,stream_end,5},{dets,do_apply_op,4}]}}. > > ** dets: Stacktrace: > [{dets,stream_end,5},{dets,do_apply_op,4},{proc_lib,init_p_do_apply,3}] > ok > > I've seen the same behaviour for sets and bags, and when the delete is > replaced by an insert (although that's a little harder to provoke). > Sample output from a QuickCheck run that shows the latter case is below > (but it looks like the same bug). > > I'm attaching the QuickCheck spec that found these race conditions > also--I can provide the right version of QuickCheck to run it and a > trial licence if desired. It just focusses on the subset of operations > in these examples, and its pretty good at finding a variety of > variations on the theme. > > 6> eqc:check(dets_eqc:prop_parallel(),eqc:counterexample()). > > =INFO REPORT==== 20-Sep-2010::17:01:59 === > ** dets: (debug) using disk map for dets_table > > =INFO REPORT==== 20-Sep-2010::17:01:59 === > ** dets: (debug) using disk map for dets_table > > =ERROR REPORT==== 20-Sep-2010::17:01:59 === > ** dets: Bug was found when accessing table dets_table, > ** dets: operation was {insert,[]} and reply was > {'EXIT',{function_clause,[{dets_v9,eval_key1,[[{0,insert_new}],[],[],bag,{0,0},[],[],0,[]]},{dets_v9,eval_key,9},{dets_v9,eval_slot,9},{dets_v9,eval_bucket_keys,8},{dets_v9,read_buckets,11},{dets,update_cache,2},{dets,stream_end,5},{dets,do_apply_op,4}]}}. > > ** dets: Stacktrace: > [{dets,stream_end,5},{dets,do_apply_op,4},{proc_lib,init_p_do_apply,3}] > Failed! Reason: > {'EXIT',{timeout,1000}} > 100 > {[{set,{var,1},{call,dets_eqc,open_file,[dets_table,[{type,bag}]]}}], > [[{set,{var,17},{call,dets,insert_new,[{var,1},{0,0}]}}], > [{set,{var,19},{call,dets,insert,[{var,1},[]]}}]]} > false > 7> > =ERROR REPORT==== 20-Sep-2010::17:02:00 === > Error in process <0.14925.0> with exit value: > {badarg,[{dets,insert_new,[dets_table,{0,0}]},{eqc_run_parallel_commands,run_child,3}]} > > > John > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com From john.hughes@REDACTED Mon Sep 20 18:13:36 2010 From: john.hughes@REDACTED (John Hughes) Date: Mon, 20 Sep 2010 18:13:36 +0200 Subject: [erlang-bugs] Two bugs in dets In-Reply-To: <4C9783B5.4080408@erlang-solutions.com> References: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com> <0F93A380-1AB7-4CE3-B0FB-08A7FDFBA360@mac.com> <4C9783B5.4080408@erlang-solutions.com> Message-ID: Mea culpa. I had defined a local open_file that just returned T, then changed it at the last moment to simplify the mail, but forgot to change the calls! :-( John ----- Original Message ----- From: "Ulf Wiger" To: "John Hughes" Cc: Sent: Monday, September 20, 2010 5:54 PM Subject: Re: [erlang-bugs] Two bugs in dets > > I got the same thing when running your examples, but > the code requires two minor corrections: > > dets:open_file/2 returns {ok, T}, not just T. > > BR, > Ulf W > > On 20/09/2010 17:09, John Hughes wrote: >> I've been using dets as an example for some new QuickCheck features, and >> seem to have discovered a couple of race conditions. >> >> Firstly, insert_new is documented as returning a bool, but under certain >> circumstances it can return ok instead. This code prints ok every time >> on my machine (R14B under Windows): >> >> bug1() -> >> T = dets:open_file(dets_table,[{type,bag}]), >> spawn(fun()->dets:insert(T,[]) end), >> spawn(fun()->io:format("~p\n",[dets:insert_new(T,[])]) end). >> >> Both spawns are necessary to make this happen--otherwise the output is >> true, as it should be. >> >> Secondly, the following code causes a bug message to appear: >> >> bug3() -> >> file:delete(dets_table), >> T = dets:open_file(dets_table,[{type,set}]), >> spawn(fun() -> dets:delete(T,0) end), >> spawn(fun() -> dets:insert_new(T,{0,0}) end), >> ok. >> >> When I run this with DETS_DEBUG set, I see this output: >> >> 87> dets_bugs:bug3(). >> >> =ERROR REPORT==== 20-Sep-2010::16:54:35 === >> ** dets: Bug was found when accessing table dets_table, >> ** dets: operation was {delete_key,[0]} and reply was >> {'EXIT',{function_clause,[{dets_v9,eval_key1,[[{1,insert_new}],[],[],set,{0,0},[],[],0,[]]},{dets_v9,eval_key,9},{dets_v9,eval_slot,9},{dets_v9,eval_bucket_keys,8},{dets_v9,read_buckets,11},{dets,update_cache,2},{dets,stream_end,5},{dets,do_apply_op,4}]}}. >> >> ** dets: Stacktrace: >> [{dets,stream_end,5},{dets,do_apply_op,4},{proc_lib,init_p_do_apply,3}] >> ok >> >> I've seen the same behaviour for sets and bags, and when the delete is >> replaced by an insert (although that's a little harder to provoke). >> Sample output from a QuickCheck run that shows the latter case is below >> (but it looks like the same bug). >> >> I'm attaching the QuickCheck spec that found these race conditions >> also--I can provide the right version of QuickCheck to run it and a >> trial licence if desired. It just focusses on the subset of operations >> in these examples, and its pretty good at finding a variety of >> variations on the theme. >> >> 6> eqc:check(dets_eqc:prop_parallel(),eqc:counterexample()). >> >> =INFO REPORT==== 20-Sep-2010::17:01:59 === >> ** dets: (debug) using disk map for dets_table >> >> =INFO REPORT==== 20-Sep-2010::17:01:59 === >> ** dets: (debug) using disk map for dets_table >> >> =ERROR REPORT==== 20-Sep-2010::17:01:59 === >> ** dets: Bug was found when accessing table dets_table, >> ** dets: operation was {insert,[]} and reply was >> {'EXIT',{function_clause,[{dets_v9,eval_key1,[[{0,insert_new}],[],[],bag,{0,0},[],[],0,[]]},{dets_v9,eval_key,9},{dets_v9,eval_slot,9},{dets_v9,eval_bucket_keys,8},{dets_v9,read_buckets,11},{dets,update_cache,2},{dets,stream_end,5},{dets,do_apply_op,4}]}}. >> >> ** dets: Stacktrace: >> [{dets,stream_end,5},{dets,do_apply_op,4},{proc_lib,init_p_do_apply,3}] >> Failed! Reason: >> {'EXIT',{timeout,1000}} >> 100 >> {[{set,{var,1},{call,dets_eqc,open_file,[dets_table,[{type,bag}]]}}], >> [[{set,{var,17},{call,dets,insert_new,[{var,1},{0,0}]}}], >> [{set,{var,19},{call,dets,insert,[{var,1},[]]}}]]} >> false >> 7> >> =ERROR REPORT==== 20-Sep-2010::17:02:00 === >> Error in process <0.14925.0> with exit value: >> {badarg,[{dets,insert_new,[dets_table,{0,0}]},{eqc_run_parallel_commands,run_child,3}]} >> >> >> John >> >> >> >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > > -- > Ulf Wiger > CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd > http://www.erlang-solutions.com > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > > From fdmanana@REDACTED Tue Sep 21 13:02:18 2010 From: fdmanana@REDACTED (Filipe David Manana) Date: Tue, 21 Sep 2010 12:02:18 +0100 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: <4C9765F0.7090801@erix.ericsson.se> References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> Message-ID: On Mon, Sep 20, 2010 at 2:47 PM, Ingela Anderton Andin < ingela@REDACTED> wrote: > So I definitely consider this a regression :( >> > > The weird thing is that I can use this certificates file with the old ssl > implementation (default on R13 and R12 releases) on R13B03 and R13B04 at > least. > Well the thing is that the old ssl-implementation only is an erlang-glue > that leaves the most things up to the underlaying openssl implementation, > but the new ssl > only uses openssl crypto library and takes care the ssl protocol > fsm-machinery and certificate handling on its own. This makes many things > much easier to implement > and removes the bottleneck enforced by the glue, and also lessens the > required resource allocation. Of course this may cause new bugs occasionally > and we fix them > as fast as we can. > If you want to try out the latest changes to fix the DSS-Params bug you can > get the branch ia/ssl-asn1-spec-dss-params at my github account > git@REDACTED:IngelaAndin/otp.git Hi, Ingela, I tried your git branch ssl-asn1-spec-dss-params but unfortunatelly I still get an exception: =ERROR REPORT==== 21-Sep-2010::11:57:03 === SSL: 1060: error:{error, {asn1, {{case_clause,19}, [{'OTP-PUB-KEY', check_and_convert_restricted_string,5}, {'OTP-PUB-KEY',decode,2}, {pubkey_cert_records,transform,2}, {lists,map,2}, {lists,map,2}, {pubkey_cert_records,transform,2}, {pubkey_cert_records,decode_tbs,1}, {pubkey_cert_records,decode_cert,2}]}}} /home/fdmanana/tmp/ibrowse-test/ca-certificates.crt [] ** exception error: no match of right hand side value {error,ecacertfile} And btw, with the old ssl implementation, using a ssl socket in {active, once} mode, I receive very often an error like this: [Thu, 16 Sep 2010 00:10:34 GMT] [error] [<0.604.0>] ** Generic server <0.604.0> terminating ** Last message in was {tcp,#Port<0.2288>, <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>} ** When Server state == {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false, [{mode,binary}, {nodelay,true}, {active,once}, {packet,0}, {ip,{0,0,0,0}}, {verify,0}, {depth,1}], {sslsocket,11,<0.604.0>}, #Port<0.2288>,nil,open,false,false} The data, third argument of the tuple, is what is supposed to be. However the ssl module trows that exception (since it was expecting to receive only messages like {ssl, Socket, Data}). Is this a known issue? cheers > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From hans.bolinder@REDACTED Tue Sep 21 13:41:10 2010 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Tue, 21 Sep 2010 13:41:10 +0200 Subject: [erlang-bugs] Two bugs in dets In-Reply-To: References: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com> <0F93A380-1AB7-4CE3-B0FB-08A7FDFBA360@mac.com> Message-ID: <19608.39382.266684.574409@ornendil.du.uab.ericsson.se> [John Hughes:] > Firstly, insert_new is documented as returning a bool, but under certain > circumstances it can return ok instead. This code prints ok every time on my > machine (R14B under Windows): > ... Thanks for reporting this bug. A fix will appear on GitHub shortly. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From ingela@REDACTED Tue Sep 21 14:07:24 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 21 Sep 2010 14:07:24 +0200 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> Message-ID: <4C989FFC.9060806@erix.ericsson.se> Hi! Filipe David Manana wrote: > On Mon, Sep 20, 2010 at 2:47 PM, Ingela Anderton Andin < > ingela@REDACTED> wrote: > > >> So I definitely consider this a regression :( >> >> The weird thing is that I can use this certificates file with the old ssl >> implementation (default on R13 and R12 releases) on R13B03 and R13B04 at >> least. >> Well the thing is that the old ssl-implementation only is an erlang-glue >> that leaves the most things up to the underlaying openssl implementation, >> but the new ssl >> only uses openssl crypto library and takes care the ssl protocol >> fsm-machinery and certificate handling on its own. This makes many things >> much easier to implement >> and removes the bottleneck enforced by the glue, and also lessens the >> required resource allocation. Of course this may cause new bugs occasionally >> and we fix them >> as fast as we can. >> If you want to try out the latest changes to fix the DSS-Params bug you can >> get the branch ia/ssl-asn1-spec-dss-params at my github account >> git@REDACTED:IngelaAndin/otp.git >> > > > Hi, > > Ingela, I tried your git branch ssl-asn1-spec-dss-params but unfortunatelly > I still get an exception: > > =ERROR REPORT==== 21-Sep-2010::11:57:03 === > SSL: 1060: error:{error, > {asn1, > {{case_clause,19}, > [{'OTP-PUB-KEY', > check_and_convert_restricted_string,5}, > {'OTP-PUB-KEY',decode,2}, > {pubkey_cert_records,transform,2}, > {lists,map,2}, > {lists,map,2}, > {pubkey_cert_records,transform,2}, > {pubkey_cert_records,decode_tbs,1}, > {pubkey_cert_records,decode_cert,2}]}}} > /home/fdmanana/tmp/ibrowse-test/ca-certificates.crt > [] > > ** exception error: no match of right hand side value {error,ecacertfile} > > > Yes I get this too, it seems to be that one of the certificates in the file has a field that is utf8-encoded but the asn-1-spec says that it should be a "printableString". I do not know if openssl tries to decode it, it might not until it is used, and it might not be. Erlang ssl caches all cert in the ca-file. I have now made new ssl more tolerant so that it will ignore such ca-certs, that does not follow the spec. I have pushed the change to the ia/ssl-asn1-spec-dss-params branch. > And btw, with the old ssl implementation, using a ssl socket in {active, > once} mode, I receive very often an error like this: > > [Thu, 16 Sep 2010 00:10:34 GMT] [error] [<0.604.0>] ** Generic server > <0.604.0> terminating > ** Last message in was {tcp,#Port<0.2288>, > > <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>} > ** When Server state == > {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false, > [{mode,binary}, > {nodelay,true}, > {active,once}, > {packet,0}, > {ip,{0,0,0,0}}, > {verify,0}, > {depth,1}], > {sslsocket,11,<0.604.0>}, > #Port<0.2288>,nil,open,false,false} > > > The data, third argument of the tuple, is what is supposed to be. However > the ssl module trows that exception (since it was expecting to receive only > messages like {ssl, Socket, Data}). Is this a known issue? > > > Humm ... not that I know of. We are aiming to remove the old ssl-implementation as soon as the new one is compleate enough and in first hand we do not fix things in the old implementation. Regards Ingela Erlang/OTP team - Ericsson AB From john.hughes@REDACTED Tue Sep 21 15:17:31 2010 From: john.hughes@REDACTED (John Hughes) Date: Tue, 21 Sep 2010 15:17:31 +0200 Subject: Another race condition in dets--open_file causes inconsistent view in another process In-Reply-To: <19608.39382.266684.574409@ornendil.du.uab.ericsson.se> References: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com><0F93A380-1AB7-4CE3-B0FB-08A7FDFBA360@mac.com> <19608.39382.266684.574409@ornendil.du.uab.ericsson.se> Message-ID: <39D9B41BEF1F47F18AA9A1BF4EF4E329@JohnsTablet2009> QuickChecking dets has turned up another race condition (this one found by the Chalmers ProTest team). Calling open_file in one process can cause another process using the same table to see an inconsistent view of the data. The simplest example is illustrated by bug1a() -> dets:close(dets_table), file:delete(dets_table), {ok,T} = dets:open_file(dets_table,[{type,bag}]), spawn(fun() -> dets:open_file(dets_table,[{type,bag}]) end), spawn(fun() -> dets:insert(dets_table,[{0,0}]), io:format("~p\n",[get_contents(dets_table)]) end). which should always print [{0,0}], but sometimes prints []. get_contents just fetches the entire table contents: get_contents(Name) -> dets:traverse(Name,fun(X)->{continue,X}end). Since the insertion and the traversal occur in the SAME process, one would expect the traversal to see the inserted data... but it doesn't always. Presumably the same bug is visible in this example, where the change that's lost is a deletion instead: bug1b() -> dets:close(dets_table), file:delete(dets_table), {ok,T} = dets:open_file(dets_table,[{type,bag}]), dets:insert(dets_table,{7,0}), spawn(fun() -> dets:open_file(dets_table,[{type,bag}]) end), spawn(fun() -> dets:delete(dets_table,7), io:format("~p\n",[get_contents(dets_table)]) end). which should always print [], but sometimes prints [{7,0}]. These examples do fail, but I'm afraid they fail pretty rarely--in the nature of race conditions, I suppose. It's a lot easier to provoke the failures with QuickCheck than by running bug1a and bug1b, because they have to be run so many times. When running them repeatedly, you also need to worry about one test case overlapping with the next. Here's a version of bug1a() with enough synchronization to prevent that: bug1c() -> Self = self(), spawn(fun() -> [dets:close(dets_table) || _ <- "abcdefghijkl"], file:delete(dets_table), Parent = self(), {ok,T} = dets:open_file(dets_table,[{type,bag}]), spawn(fun() -> dets:open_file(dets_table,[{type,bag}]), Parent ! done end), spawn(fun() -> dets:insert(dets_table,[{0,0}]), io:format("~p\n",[get_contents(dets_table)]), Parent ! done end), receive done -> receive done -> ok end end, Self ! ok end), receive ok -> ok end. Running this 1,000 times will print [] a few times, revealing the bug. Alternatively, compiling the attached file with options {d,'BUG_OPEN_FILE',true} and running QuickCheck on prop_parallel() provokes the bug within a few hundred tests. This needs the latest version of QuickCheck, 1.22, for the latest race condition testing code. John -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dets_eqc.erl Type: application/octet-stream Size: 5328 bytes Desc: not available URL: From fdmanana@REDACTED Tue Sep 21 15:37:40 2010 From: fdmanana@REDACTED (Filipe David Manana) Date: Tue, 21 Sep 2010 14:37:40 +0100 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: <4C989FFC.9060806@erix.ericsson.se> References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> <4C989FFC.9060806@erix.ericsson.se> Message-ID: Ingela, After pulling your last commit, things advance a bit more, but still not able to open the CAs file: =INFO REPORT==== 21-Sep-2010::14:35:58 === SSL WARNING: Ignoring CA cert: <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, 156,82,75,84,82,85,83,84,32,69,108,101,107, 116,114,111,110,105,107,32,83,101,114,116,105, 102,105,107,97,32,72,105,122,109,101,116,32, 83,97,196,159,108,97,121,196,177,99,196,177, 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, 48,48,53,32,84,195,156,82,75,84,82,85,83,84, 32,66,105,108,103,105,32,196,176,108,101,116, 105,197,159,105,109,32,118,101,32,66,105,108, 105,197,159,105,109,32,71,195,188,118,101,110, 108,105,196,159,105,32,72,105,122,109,101,116, 108,101,114,105,32,65,46,197,158,46,48,30,23, 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, 156,82,75,84,82,85,83,84,32,69,108,101,107, 116,114,111,110,105,107,32,83,101,114,116,105, 102,105,107,97,32,72,105,122,109,101,116,32, 83,97,196,159,108,97,121,196,177,99,196,177, 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, 48,48,53,32,84,195,156,82,75,84,82,85,83,84, 32,66,105,108,103,105,32,196,176,108,101,116, 105,197,159,105,109,32,118,101,32,66,105,108, 105,197,159,105,109,32,71,195,188,118,101,110, 108,105,196,159,105,32,72,105,122,109,101,116, 108,101,114,105,32,65,46,197,158,46,48,130,1, 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, 214,99,3,216,28,95,221,210,123,93,242,12,96, 97,91,107,59,116,43,120,13,125,69,189,34,116, 232,140,3,193,198,17,42,61,149,188,169,148, 176,187,145,151,200,105,124,132,197,180,145, 108,108,19,106,164,85,173,164,133,232,149,126, 179,0,175,0,194,5,24,245,112,157,54,139,174, 203,228,27,129,127,147,136,251,106,85,187,125, 133,146,206,186,88,159,219,50,197,189,93,239, 34,74,47,65,7,126,73,97,179,134,236,78,166,65, 110,132,188,3,236,245,59,28,200,31,194,238, 168,238,234,18,74,141,20,207,243,10,224,80,57, 249,8,53,248,17,89,173,231,34,234,75,202,20,6, 222,66,186,178,153,243,45,84,136,16,6,234,225, 26,62,61,103,31,251,206,251,124,130,232,17,93, 74,193,185,20,234,84,217,102,155,124,137,125, 4,154,98,201,233,82,60,158,156,239,210,245,38, 228,230,229,24,124,139,110,223,108,204,120,91, 79,114,178,203,92,63,140,5,141,209,76,140,173, 146,199,225,120,127,101,108,73,6,80,44,158,50, 194,215,74,198,117,138,89,78,117,111,71,94, 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, 128,89,33,164,252,161,21,76,32,246,212,95,218, 3,36,252,207,144,26,244,33,10,154,238,58,177, 106,239,239,248,96,209,76,54,102,69,29,243, 102,2,116,4,123,146,48,168,222,10,118,15,239, 149,110,189,201,55,230,26,13,172,137,72,91, 204,131,54,194,245,70,92,89,130,86,180,213, 254,35,180,216,84,28,68,171,196,167,229,20, 206,60,65,97,124,67,230,205,196,129,9,139,36, 251,84,37,214,22,168,150,12,103,7,111,179,80, 71,227,28,36,40,221,42,152,164,97,254,219,234, 18,55,188,1,26,52,133,189,110,79,231,145,114, 7,68,133,30,88,202,84,68,221,247,172,185,203, 137,33,114,219,143,192,105,41,151,42,163,174, 24,35,151,28,65,42,139,124,42,193,124,144,232, 169,40,192,211,145,198,173,40,135,64,104,181, 255,236,167,210,211,56,24,156,211,125,105,93, 240,198,165,30,36,27,163,71,252,105,7,104,231, 228,154,180,237,15,161,135,135,2,206,135,210, 72,78,225,188,255,203,241,114,146,68,100,3,37, 234,222,91,110,159,201,242,78,172,221,199>> Due to decoding error:{badmatch, {error, {asn1, {{case_clause,19}, [{'OTP-PUB-KEY', check_and_convert_restricted_string,5}, {'OTP-PUB-KEY',decode,2}, {pubkey_cert_records,transform,2}, {lists,map,2}, {lists,map,2}, {pubkey_cert_records,transform,2}, {pubkey_cert_records,decode_tbs,1}, {pubkey_cert_records,decode_cert,1}]}}}} =ERROR REPORT==== 21-Sep-2010::14:35:58 === SSL: certify_certificate: ./ssl_handshake.erl:584:Fatal error: handshake failure ** exception error: no match of right hand side value {error,esslconnect} in function ssl_test:test/0 cheers On Tue, Sep 21, 2010 at 1:07 PM, Ingela Anderton Andin < ingela@REDACTED> wrote: > Hi! > > Filipe David Manana wrote: > >> On Mon, Sep 20, 2010 at 2:47 PM, Ingela Anderton Andin < >> ingela@REDACTED> wrote: >> >> >> >>> So I definitely consider this a regression :( >>> The weird thing is that I can use this certificates file with the old >>> ssl >>> implementation (default on R13 and R12 releases) on R13B03 and R13B04 at >>> least. >>> Well the thing is that the old ssl-implementation only is an erlang-glue >>> that leaves the most things up to the underlaying openssl implementation, >>> but the new ssl >>> only uses openssl crypto library and takes care the ssl protocol >>> fsm-machinery and certificate handling on its own. This makes many >>> things >>> much easier to implement >>> and removes the bottleneck enforced by the glue, and also lessens the >>> required resource allocation. Of course this may cause new bugs >>> occasionally >>> and we fix them >>> as fast as we can. >>> If you want to try out the latest changes to fix the DSS-Params bug you >>> can >>> get the branch ia/ssl-asn1-spec-dss-params at my github account >>> git@REDACTED:IngelaAndin/otp.git >>> >>> >> >> >> Hi, >> >> Ingela, I tried your git branch ssl-asn1-spec-dss-params but >> unfortunatelly >> I still get an exception: >> >> =ERROR REPORT==== 21-Sep-2010::11:57:03 === >> SSL: 1060: error:{error, >> {asn1, >> {{case_clause,19}, >> [{'OTP-PUB-KEY', >> check_and_convert_restricted_string,5}, >> {'OTP-PUB-KEY',decode,2}, >> {pubkey_cert_records,transform,2}, >> {lists,map,2}, >> {lists,map,2}, >> {pubkey_cert_records,transform,2}, >> {pubkey_cert_records,decode_tbs,1}, >> {pubkey_cert_records,decode_cert,2}]}}} >> /home/fdmanana/tmp/ibrowse-test/ca-certificates.crt >> [] >> >> ** exception error: no match of right hand side value {error,ecacertfile} >> >> >> >> > > Yes I get this too, it seems to be that one of the certificates in the file > has a field that is utf8-encoded but the asn-1-spec says that it should > be a "printableString". I do not know if openssl tries to decode it, it > might > not until it is used, and it might not be. Erlang ssl caches all cert in > the ca-file. > I have now made new ssl more tolerant so that it > will ignore such ca-certs, that does not follow the spec. I have pushed > the change to > the ia/ssl-asn1-spec-dss-params branch. > > > And btw, with the old ssl implementation, using a ssl socket in {active, >> once} mode, I receive very often an error like this: >> >> [Thu, 16 Sep 2010 00:10:34 GMT] [error] [<0.604.0>] ** Generic server >> <0.604.0> terminating >> ** Last message in was {tcp,#Port<0.2288>, >> >> >> <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>} >> ** When Server state == >> {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false, >> [{mode,binary}, >> {nodelay,true}, >> {active,once}, >> {packet,0}, >> {ip,{0,0,0,0}}, >> {verify,0}, >> {depth,1}], >> {sslsocket,11,<0.604.0>}, >> #Port<0.2288>,nil,open,false,false} >> >> >> The data, third argument of the tuple, is what is supposed to be. However >> the ssl module trows that exception (since it was expecting to receive >> only >> messages like {ssl, Socket, Data}). Is this a known issue? >> >> >> >> > > Humm ... not that I know of. We are aiming to remove the old > ssl-implementation as soon as the new one is compleate enough and > in first hand we do not fix things in the old implementation. > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From ingela@REDACTED Tue Sep 21 17:07:29 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 21 Sep 2010 17:07:29 +0200 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> <4C989FFC.9060806@erix.ericsson.se> Message-ID: <4C98CA31.4010301@erix.ericsson.se> Hi! Yes you could, it is a INFO report a warning that that particular CA cert is ignored as we could not decode it. But you get another handshake error. What options do you connect with ? Regards Ingela Erlang/OTP team - Ericsson AB Filipe David Manana wrote: > Ingela, > > After pulling your last commit, things advance a bit more, but still > not able to open the CAs file: > > =INFO REPORT==== 21-Sep-2010::14:35:58 === > SSL WARNING: Ignoring CA cert: > <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, > > 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, > > 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, > > 156,82,75,84,82,85,83,84,32,69,108,101,107, > > 116,114,111,110,105,107,32,83,101,114,116,105, > > 102,105,107,97,32,72,105,122,109,101,116,32, > > 83,97,196,159,108,97,121,196,177,99,196,177, > > 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, > > 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, > > 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, > > 48,48,53,32,84,195,156,82,75,84,82,85,83,84, > > 32,66,105,108,103,105,32,196,176,108,101,116, > > 105,197,159,105,109,32,118,101,32,66,105,108, > > 105,197,159,105,109,32,71,195,188,118,101,110, > > 108,105,196,159,105,32,72,105,122,109,101,116, > > 108,101,114,105,32,65,46,197,158,46,48,30,23, > > 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, > > 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, > > 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, > > 156,82,75,84,82,85,83,84,32,69,108,101,107, > > 116,114,111,110,105,107,32,83,101,114,116,105, > > 102,105,107,97,32,72,105,122,109,101,116,32, > > 83,97,196,159,108,97,121,196,177,99,196,177, > > 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, > > 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, > > 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, > > 48,48,53,32,84,195,156,82,75,84,82,85,83,84, > > 32,66,105,108,103,105,32,196,176,108,101,116, > > 105,197,159,105,109,32,118,101,32,66,105,108, > > 105,197,159,105,109,32,71,195,188,118,101,110, > > 108,105,196,159,105,32,72,105,122,109,101,116, > > 108,101,114,105,32,65,46,197,158,46,48,130,1, > > 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, > > 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, > > 214,99,3,216,28,95,221,210,123,93,242,12,96, > > 97,91,107,59,116,43,120,13,125,69,189,34,116, > > 232,140,3,193,198,17,42,61,149,188,169,148, > > 176,187,145,151,200,105,124,132,197,180,145, > > 108,108,19,106,164,85,173,164,133,232,149,126, > > 179,0,175,0,194,5,24,245,112,157,54,139,174, > > 203,228,27,129,127,147,136,251,106,85,187,125, > > 133,146,206,186,88,159,219,50,197,189,93,239, > > 34,74,47,65,7,126,73,97,179,134,236,78,166,65, > > 110,132,188,3,236,245,59,28,200,31,194,238, > > 168,238,234,18,74,141,20,207,243,10,224,80,57, > > 249,8,53,248,17,89,173,231,34,234,75,202,20,6, > > 222,66,186,178,153,243,45,84,136,16,6,234,225, > > 26,62,61,103,31,251,206,251,124,130,232,17,93, > > 74,193,185,20,234,84,217,102,155,124,137,125, > > 4,154,98,201,233,82,60,158,156,239,210,245,38, > > 228,230,229,24,124,139,110,223,108,204,120,91, > > 79,114,178,203,92,63,140,5,141,209,76,140,173, > > 146,199,225,120,127,101,108,73,6,80,44,158,50, > > 194,215,74,198,117,138,89,78,117,111,71,94, > > 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, > > 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, > > 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, > > 128,89,33,164,252,161,21,76,32,246,212,95,218, > > 3,36,252,207,144,26,244,33,10,154,238,58,177, > > 106,239,239,248,96,209,76,54,102,69,29,243, > > 102,2,116,4,123,146,48,168,222,10,118,15,239, > > 149,110,189,201,55,230,26,13,172,137,72,91, > > 204,131,54,194,245,70,92,89,130,86,180,213, > > 254,35,180,216,84,28,68,171,196,167,229,20, > > 206,60,65,97,124,67,230,205,196,129,9,139,36, > > 251,84,37,214,22,168,150,12,103,7,111,179,80, > > 71,227,28,36,40,221,42,152,164,97,254,219,234, > > 18,55,188,1,26,52,133,189,110,79,231,145,114, > > 7,68,133,30,88,202,84,68,221,247,172,185,203, > > 137,33,114,219,143,192,105,41,151,42,163,174, > > 24,35,151,28,65,42,139,124,42,193,124,144,232, > > 169,40,192,211,145,198,173,40,135,64,104,181, > > 255,236,167,210,211,56,24,156,211,125,105,93, > > 240,198,165,30,36,27,163,71,252,105,7,104,231, > > 228,154,180,237,15,161,135,135,2,206,135,210, > > 72,78,225,188,255,203,241,114,146,68,100,3,37, > > 234,222,91,110,159,201,242,78,172,221,199>> > Due to decoding error:{badmatch, > {error, > {asn1, > {{case_clause,19}, > [{'OTP-PUB-KEY', > check_and_convert_restricted_string,5}, > {'OTP-PUB-KEY',decode,2}, > {pubkey_cert_records,transform,2}, > {lists,map,2}, > {lists,map,2}, > {pubkey_cert_records,transform,2}, > {pubkey_cert_records,decode_tbs,1}, > {pubkey_cert_records,decode_cert,1}]}}}} > > > =ERROR REPORT==== 21-Sep-2010::14:35:58 === > SSL: certify_certificate: ./ssl_handshake.erl:584:Fatal error: > handshake failure > ** exception error: no match of right hand side value {error,esslconnect} > in function ssl_test:test/0 > > > cheers > > On Tue, Sep 21, 2010 at 1:07 PM, Ingela Anderton Andin > > wrote: > > Hi! > > Filipe David Manana wrote: > > On Mon, Sep 20, 2010 at 2:47 PM, Ingela Anderton Andin < > ingela@REDACTED > wrote: > > > > So I definitely consider this a regression :( > The weird thing is that I can use this certificates > file with the old ssl > implementation (default on R13 and R12 releases) on R13B03 > and R13B04 at > least. > Well the thing is that the old ssl-implementation only is > an erlang-glue > that leaves the most things up to the underlaying openssl > implementation, > but the new ssl > only uses openssl crypto library and takes care the ssl > protocol > fsm-machinery and certificate handling on its own. This > makes many things > much easier to implement > and removes the bottleneck enforced by the glue, and also > lessens the > required resource allocation. Of course this may cause new > bugs occasionally > and we fix them > as fast as we can. > If you want to try out the latest changes to fix the > DSS-Params bug you can > get the branch ia/ssl-asn1-spec-dss-params at my github > account > git@REDACTED:IngelaAndin/otp.git > > > > > Hi, > > Ingela, I tried your git branch ssl-asn1-spec-dss-params but > unfortunatelly > I still get an exception: > > =ERROR REPORT==== 21-Sep-2010::11:57:03 === > SSL: 1060: error:{error, > {asn1, > {{case_clause,19}, > [{'OTP-PUB-KEY', > > check_and_convert_restricted_string,5}, > {'OTP-PUB-KEY',decode,2}, > {pubkey_cert_records,transform,2}, > {lists,map,2}, > {lists,map,2}, > {pubkey_cert_records,transform,2}, > {pubkey_cert_records,decode_tbs,1}, > {pubkey_cert_records,decode_cert,2}]}}} > /home/fdmanana/tmp/ibrowse-test/ca-certificates.crt > [] > > ** exception error: no match of right hand side value > {error,ecacertfile} > > > > > > Yes I get this too, it seems to be that one of the certificates in > the file > has a field that is utf8-encoded but the asn-1-spec says that it > should > be a "printableString". I do not know if openssl tries to decode > it, it might > not until it is used, and it might not be. Erlang ssl caches all > cert in the ca-file. > I have now made new ssl more tolerant so that it > will ignore such ca-certs, that does not follow the spec. I have > pushed the change to > the ia/ssl-asn1-spec-dss-params branch. > > > And btw, with the old ssl implementation, using a ssl socket > in {active, > once} mode, I receive very often an error like this: > > [Thu, 16 Sep 2010 00:10:34 GMT] [error] [<0.604.0>] ** Generic > server > <0.604.0> terminating > ** Last message in was {tcp,#Port<0.2288>, > > <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>} > ** When Server state == > {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false, > [{mode,binary}, > {nodelay,true}, > {active,once}, > {packet,0}, > {ip,{0,0,0,0}}, > {verify,0}, > {depth,1}], > {sslsocket,11,<0.604.0>}, > #Port<0.2288>,nil,open,false,false} > > > The data, third argument of the tuple, is what is supposed to > be. However > the ssl module trows that exception (since it was expecting to > receive only > messages like {ssl, Socket, Data}). Is this a known issue? > > > > > > Humm ... not that I know of. We are aiming to remove the old > ssl-implementation as soon as the new one is compleate enough and > in first hand we do not fix things in the old implementation. > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > > > > > -- > Filipe David Manana, > fdmanana@REDACTED , fdmanana@REDACTED > > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > From fdmanana@REDACTED Tue Sep 21 17:15:30 2010 From: fdmanana@REDACTED (Filipe David Manana) Date: Tue, 21 Sep 2010 16:15:30 +0100 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: <4C98CA31.4010301@erix.ericsson.se> References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> <4C989FFC.9060806@erix.ericsson.se> <4C98CA31.4010301@erix.ericsson.se> Message-ID: On Tue, Sep 21, 2010 at 4:07 PM, Ingela Anderton Andin < ingela@REDACTED> wrote: > Hi! > > Yes you could, it is a INFO report a warning that that particular CA cert > is ignored as we could not decode it. > But you get another handshake error. What options do you connect with ? This is an excerpt of my testing code: Options = [ {ssl_imp, new}, binary, {nodelay, true}, {active, false}, {verify, verify_peer}, {depth, 3}, {cacertfile, "/etc/ssl/certs/ca-certificates.crt"} ], {ok, S} = ssl:connect(?HOST, 443, Options), ok = ssl:send(S, Body), loop(S), ssl:close(S). loop(S) -> ssl:setopts(S, [{active, once}]), receive {ssl, S, Data} -> io:format("received data: ~p~n", [Data]), loop(S); {ssl_closed, S} -> io:format("socket closed", []); {ssl_error, S, Error} -> io:format("socket error: ~p~n", [Error]) end. Once again, thanks for looking into this. > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > Filipe David Manana wrote: > >> Ingela, >> >> After pulling your last commit, things advance a bit more, but still not >> able to open the CAs file: >> >> =INFO REPORT==== 21-Sep-2010::14:35:58 === >> SSL WARNING: Ignoring CA cert: >> <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, >> >> 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, >> >> 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, >> >> 156,82,75,84,82,85,83,84,32,69,108,101,107, >> >> 116,114,111,110,105,107,32,83,101,114,116,105, >> >> 102,105,107,97,32,72,105,122,109,101,116,32, >> >> 83,97,196,159,108,97,121,196,177,99,196,177, >> >> 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, >> >> 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, >> >> 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, >> >> 48,48,53,32,84,195,156,82,75,84,82,85,83,84, >> >> 32,66,105,108,103,105,32,196,176,108,101,116, >> >> 105,197,159,105,109,32,118,101,32,66,105,108, >> >> 105,197,159,105,109,32,71,195,188,118,101,110, >> >> 108,105,196,159,105,32,72,105,122,109,101,116, >> >> 108,101,114,105,32,65,46,197,158,46,48,30,23, >> >> 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, >> >> 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, >> >> 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, >> >> 156,82,75,84,82,85,83,84,32,69,108,101,107, >> >> 116,114,111,110,105,107,32,83,101,114,116,105, >> >> 102,105,107,97,32,72,105,122,109,101,116,32, >> >> 83,97,196,159,108,97,121,196,177,99,196,177, >> >> 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, >> >> 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, >> >> 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, >> >> 48,48,53,32,84,195,156,82,75,84,82,85,83,84, >> >> 32,66,105,108,103,105,32,196,176,108,101,116, >> >> 105,197,159,105,109,32,118,101,32,66,105,108, >> >> 105,197,159,105,109,32,71,195,188,118,101,110, >> >> 108,105,196,159,105,32,72,105,122,109,101,116, >> >> 108,101,114,105,32,65,46,197,158,46,48,130,1, >> >> 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, >> >> 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, >> >> 214,99,3,216,28,95,221,210,123,93,242,12,96, >> >> 97,91,107,59,116,43,120,13,125,69,189,34,116, >> >> 232,140,3,193,198,17,42,61,149,188,169,148, >> >> 176,187,145,151,200,105,124,132,197,180,145, >> >> 108,108,19,106,164,85,173,164,133,232,149,126, >> >> 179,0,175,0,194,5,24,245,112,157,54,139,174, >> >> 203,228,27,129,127,147,136,251,106,85,187,125, >> >> 133,146,206,186,88,159,219,50,197,189,93,239, >> >> 34,74,47,65,7,126,73,97,179,134,236,78,166,65, >> >> 110,132,188,3,236,245,59,28,200,31,194,238, >> >> 168,238,234,18,74,141,20,207,243,10,224,80,57, >> >> 249,8,53,248,17,89,173,231,34,234,75,202,20,6, >> >> 222,66,186,178,153,243,45,84,136,16,6,234,225, >> >> 26,62,61,103,31,251,206,251,124,130,232,17,93, >> >> 74,193,185,20,234,84,217,102,155,124,137,125, >> >> 4,154,98,201,233,82,60,158,156,239,210,245,38, >> >> 228,230,229,24,124,139,110,223,108,204,120,91, >> >> 79,114,178,203,92,63,140,5,141,209,76,140,173, >> >> 146,199,225,120,127,101,108,73,6,80,44,158,50, >> >> 194,215,74,198,117,138,89,78,117,111,71,94, >> >> 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, >> >> 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, >> >> 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, >> >> 128,89,33,164,252,161,21,76,32,246,212,95,218, >> >> 3,36,252,207,144,26,244,33,10,154,238,58,177, >> >> 106,239,239,248,96,209,76,54,102,69,29,243, >> >> 102,2,116,4,123,146,48,168,222,10,118,15,239, >> >> 149,110,189,201,55,230,26,13,172,137,72,91, >> >> 204,131,54,194,245,70,92,89,130,86,180,213, >> >> 254,35,180,216,84,28,68,171,196,167,229,20, >> >> 206,60,65,97,124,67,230,205,196,129,9,139,36, >> >> 251,84,37,214,22,168,150,12,103,7,111,179,80, >> >> 71,227,28,36,40,221,42,152,164,97,254,219,234, >> >> 18,55,188,1,26,52,133,189,110,79,231,145,114, >> >> 7,68,133,30,88,202,84,68,221,247,172,185,203, >> >> 137,33,114,219,143,192,105,41,151,42,163,174, >> >> 24,35,151,28,65,42,139,124,42,193,124,144,232, >> >> 169,40,192,211,145,198,173,40,135,64,104,181, >> >> 255,236,167,210,211,56,24,156,211,125,105,93, >> >> 240,198,165,30,36,27,163,71,252,105,7,104,231, >> >> 228,154,180,237,15,161,135,135,2,206,135,210, >> >> 72,78,225,188,255,203,241,114,146,68,100,3,37, >> >> 234,222,91,110,159,201,242,78,172,221,199>> >> Due to decoding error:{badmatch, >> {error, >> {asn1, >> {{case_clause,19}, >> [{'OTP-PUB-KEY', >> check_and_convert_restricted_string,5}, >> {'OTP-PUB-KEY',decode,2}, >> {pubkey_cert_records,transform,2}, >> {lists,map,2}, >> {lists,map,2}, >> {pubkey_cert_records,transform,2}, >> {pubkey_cert_records,decode_tbs,1}, >> {pubkey_cert_records,decode_cert,1}]}}}} >> >> >> =ERROR REPORT==== 21-Sep-2010::14:35:58 === >> SSL: certify_certificate: ./ssl_handshake.erl:584:Fatal error: handshake >> failure >> ** exception error: no match of right hand side value {error,esslconnect} >> in function ssl_test:test/0 >> >> >> cheers >> >> On Tue, Sep 21, 2010 at 1:07 PM, Ingela Anderton Andin < >> ingela@REDACTED > wrote: >> >> Hi! >> >> Filipe David Manana wrote: >> >> On Mon, Sep 20, 2010 at 2:47 PM, Ingela Anderton Andin < >> ingela@REDACTED > wrote: >> >> >> So I definitely consider this a regression :( >> The weird thing is that I can use this certificates >> file with the old ssl >> implementation (default on R13 and R12 releases) on R13B03 >> and R13B04 at >> least. >> Well the thing is that the old ssl-implementation only is >> an erlang-glue >> that leaves the most things up to the underlaying openssl >> implementation, >> but the new ssl >> only uses openssl crypto library and takes care the ssl >> protocol >> fsm-machinery and certificate handling on its own. This >> makes many things >> much easier to implement >> and removes the bottleneck enforced by the glue, and also >> lessens the >> required resource allocation. Of course this may cause new >> bugs occasionally >> and we fix them >> as fast as we can. >> If you want to try out the latest changes to fix the >> DSS-Params bug you can >> get the branch ia/ssl-asn1-spec-dss-params at my github >> account >> git@REDACTED:IngelaAndin/otp.git >> >> >> >> Hi, >> >> Ingela, I tried your git branch ssl-asn1-spec-dss-params but >> unfortunatelly >> I still get an exception: >> >> =ERROR REPORT==== 21-Sep-2010::11:57:03 === >> SSL: 1060: error:{error, >> {asn1, >> {{case_clause,19}, >> [{'OTP-PUB-KEY', >> >> check_and_convert_restricted_string,5}, >> {'OTP-PUB-KEY',decode,2}, >> {pubkey_cert_records,transform,2}, >> {lists,map,2}, >> {lists,map,2}, >> {pubkey_cert_records,transform,2}, >> {pubkey_cert_records,decode_tbs,1}, >> {pubkey_cert_records,decode_cert,2}]}}} >> /home/fdmanana/tmp/ibrowse-test/ca-certificates.crt >> [] >> >> ** exception error: no match of right hand side value >> {error,ecacertfile} >> >> >> >> >> Yes I get this too, it seems to be that one of the certificates in >> the file >> has a field that is utf8-encoded but the asn-1-spec says that it >> should >> be a "printableString". I do not know if openssl tries to decode >> it, it might >> not until it is used, and it might not be. Erlang ssl caches all >> cert in the ca-file. >> I have now made new ssl more tolerant so that it >> will ignore such ca-certs, that does not follow the spec. I have >> pushed the change to >> the ia/ssl-asn1-spec-dss-params branch. >> >> >> And btw, with the old ssl implementation, using a ssl socket >> in {active, >> once} mode, I receive very often an error like this: >> >> [Thu, 16 Sep 2010 00:10:34 GMT] [error] [<0.604.0>] ** Generic >> server >> <0.604.0> terminating >> ** Last message in was {tcp,#Port<0.2288>, >> >> >> <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>} >> ** When Server state == >> {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false, >> [{mode,binary}, >> {nodelay,true}, >> {active,once}, >> {packet,0}, >> {ip,{0,0,0,0}}, >> {verify,0}, >> {depth,1}], >> {sslsocket,11,<0.604.0>}, >> #Port<0.2288>,nil,open,false,false} >> >> >> The data, third argument of the tuple, is what is supposed to >> be. However >> the ssl module trows that exception (since it was expecting to >> receive only >> messages like {ssl, Socket, Data}). Is this a known issue? >> >> >> >> >> Humm ... not that I know of. We are aiming to remove the old >> ssl-implementation as soon as the new one is compleate enough and >> in first hand we do not fix things in the old implementation. >> >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> >> >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> >> >> >> >> >> -- >> Filipe David Manana, >> fdmanana@REDACTED , fdmanana@REDACTED> fdmanana@REDACTED> >> >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." >> >> > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From ingela@REDACTED Wed Sep 22 09:48:39 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 22 Sep 2010 09:48:39 +0200 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> <4C989FFC.9060806@erix.ericsson.se> <4C98CA31.4010301@erix.ericsson.se> Message-ID: <4C99B4D7.5020307@erix.ericsson.se> Hi again! Well ok, first I would like you to provide the option verify_fun: FunAndState = {fun(_,{bad_cert, _} = Reason, _) -> io:format("Reason: ~p~n", [Reason]), {fail, Reason}; (_,{extension, _}, UserState) -> {unknown, UserState}; (_, valid, UserState) -> {valid, UserState} end, []}, add option: {verify_fun, FunAndState} So we can try to find out why it does not like the cert. By the way we decided to shorten the INFO report if you would like to run the latest ssl it is now on the branch ia/ssl/public_key/backwards-compatibility/OTP-8858. Regards Ingela Erlang/OTP team - Ericsson AB Filipe David Manana wrote: > On Tue, Sep 21, 2010 at 4:07 PM, Ingela Anderton Andin > > wrote: > > Hi! > > Yes you could, it is a INFO report a warning that that particular > CA cert is ignored as we could not decode it. > But you get another handshake error. What options do you connect > with ? > > > This is an excerpt of my testing code: > > Options = [ > {ssl_imp, new}, > binary, > {nodelay, true}, > {active, false}, > {verify, verify_peer}, > {depth, 3}, > {cacertfile, "/etc/ssl/certs/ca-certificates.crt"} > ], > {ok, S} = ssl:connect(?HOST, 443, Options), > ok = ssl:send(S, Body), > loop(S), > ssl:close(S). > > loop(S) -> > ssl:setopts(S, [{active, once}]), > receive > {ssl, S, Data} -> > io:format("received data: ~p~n", [Data]), > loop(S); > {ssl_closed, S} -> > io:format("socket closed", []); > {ssl_error, S, Error} -> > io:format("socket error: ~p~n", [Error]) > end. > > > Once again, thanks for looking into this. > > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > Filipe David Manana wrote: > > Ingela, > > After pulling your last commit, things advance a bit more, but > still not able to open the CAs file: > > =INFO REPORT==== 21-Sep-2010::14:35:58 === > SSL WARNING: Ignoring CA cert: > <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, > > 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, > > 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, > > 156,82,75,84,82,85,83,84,32,69,108,101,107, > > 116,114,111,110,105,107,32,83,101,114,116,105, > > 102,105,107,97,32,72,105,122,109,101,116,32, > > 83,97,196,159,108,97,121,196,177,99,196,177, > > 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, > > 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, > > 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, > > 48,48,53,32,84,195,156,82,75,84,82,85,83,84, > > 32,66,105,108,103,105,32,196,176,108,101,116, > > 105,197,159,105,109,32,118,101,32,66,105,108, > > 105,197,159,105,109,32,71,195,188,118,101,110, > > 108,105,196,159,105,32,72,105,122,109,101,116, > > 108,101,114,105,32,65,46,197,158,46,48,30,23, > > 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, > > 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, > > 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, > > 156,82,75,84,82,85,83,84,32,69,108,101,107, > > 116,114,111,110,105,107,32,83,101,114,116,105, > > 102,105,107,97,32,72,105,122,109,101,116,32, > > 83,97,196,159,108,97,121,196,177,99,196,177, > > 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, > > 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, > > 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, > > 48,48,53,32,84,195,156,82,75,84,82,85,83,84, > > 32,66,105,108,103,105,32,196,176,108,101,116, > > 105,197,159,105,109,32,118,101,32,66,105,108, > > 105,197,159,105,109,32,71,195,188,118,101,110, > > 108,105,196,159,105,32,72,105,122,109,101,116, > > 108,101,114,105,32,65,46,197,158,46,48,130,1, > > 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, > > 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, > > 214,99,3,216,28,95,221,210,123,93,242,12,96, > > 97,91,107,59,116,43,120,13,125,69,189,34,116, > > 232,140,3,193,198,17,42,61,149,188,169,148, > > 176,187,145,151,200,105,124,132,197,180,145, > > 108,108,19,106,164,85,173,164,133,232,149,126, > > 179,0,175,0,194,5,24,245,112,157,54,139,174, > > 203,228,27,129,127,147,136,251,106,85,187,125, > > 133,146,206,186,88,159,219,50,197,189,93,239, > > 34,74,47,65,7,126,73,97,179,134,236,78,166,65, > > 110,132,188,3,236,245,59,28,200,31,194,238, > > 168,238,234,18,74,141,20,207,243,10,224,80,57, > > 249,8,53,248,17,89,173,231,34,234,75,202,20,6, > > 222,66,186,178,153,243,45,84,136,16,6,234,225, > > 26,62,61,103,31,251,206,251,124,130,232,17,93, > > 74,193,185,20,234,84,217,102,155,124,137,125, > > 4,154,98,201,233,82,60,158,156,239,210,245,38, > > 228,230,229,24,124,139,110,223,108,204,120,91, > > 79,114,178,203,92,63,140,5,141,209,76,140,173, > > 146,199,225,120,127,101,108,73,6,80,44,158,50, > > 194,215,74,198,117,138,89,78,117,111,71,94, > > 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, > > 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, > > 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, > > 128,89,33,164,252,161,21,76,32,246,212,95,218, > > 3,36,252,207,144,26,244,33,10,154,238,58,177, > > 106,239,239,248,96,209,76,54,102,69,29,243, > > 102,2,116,4,123,146,48,168,222,10,118,15,239, > > 149,110,189,201,55,230,26,13,172,137,72,91, > > 204,131,54,194,245,70,92,89,130,86,180,213, > > 254,35,180,216,84,28,68,171,196,167,229,20, > > 206,60,65,97,124,67,230,205,196,129,9,139,36, > > 251,84,37,214,22,168,150,12,103,7,111,179,80, > > 71,227,28,36,40,221,42,152,164,97,254,219,234, > > 18,55,188,1,26,52,133,189,110,79,231,145,114, > > 7,68,133,30,88,202,84,68,221,247,172,185,203, > > 137,33,114,219,143,192,105,41,151,42,163,174, > > 24,35,151,28,65,42,139,124,42,193,124,144,232, > > 169,40,192,211,145,198,173,40,135,64,104,181, > > 255,236,167,210,211,56,24,156,211,125,105,93, > > 240,198,165,30,36,27,163,71,252,105,7,104,231, > > 228,154,180,237,15,161,135,135,2,206,135,210, > > 72,78,225,188,255,203,241,114,146,68,100,3,37, > > 234,222,91,110,159,201,242,78,172,221,199>> > Due to decoding error:{badmatch, > {error, > {asn1, > {{case_clause,19}, > [{'OTP-PUB-KEY', > > check_and_convert_restricted_string,5}, > {'OTP-PUB-KEY',decode,2}, > {pubkey_cert_records,transform,2}, > {lists,map,2}, > {lists,map,2}, > {pubkey_cert_records,transform,2}, > {pubkey_cert_records,decode_tbs,1}, > > {pubkey_cert_records,decode_cert,1}]}}}} > > > =ERROR REPORT==== 21-Sep-2010::14:35:58 === > SSL: certify_certificate: ./ssl_handshake.erl:584:Fatal error: > handshake failure > ** exception error: no match of right hand side value > {error,esslconnect} > in function ssl_test:test/0 > > > cheers > > On Tue, Sep 21, 2010 at 1:07 PM, Ingela Anderton Andin > > >> wrote: > > Hi! > > Filipe David Manana wrote: > > On Mon, Sep 20, 2010 at 2:47 PM, Ingela Anderton Andin < > ingela@REDACTED > > >> wrote: > > > So I definitely consider this a regression :( > The weird thing is that I can use this certificates > file with the old ssl > implementation (default on R13 and R12 releases) on > R13B03 > and R13B04 at > least. > Well the thing is that the old ssl-implementation > only is > an erlang-glue > that leaves the most things up to the underlaying > openssl > implementation, > but the new ssl > only uses openssl crypto library and takes care the ssl > protocol > fsm-machinery and certificate handling on its > own. This > makes many things > much easier to implement > and removes the bottleneck enforced by the glue, > and also > lessens the > required resource allocation. Of course this may > cause new > bugs occasionally > and we fix them > as fast as we can. > If you want to try out the latest changes to fix the > DSS-Params bug you can > get the branch ia/ssl-asn1-spec-dss-params at my github > account > git@REDACTED:IngelaAndin/otp.git > > > > Hi, > > Ingela, I tried your git branch > ssl-asn1-spec-dss-params but > unfortunatelly > I still get an exception: > > =ERROR REPORT==== 21-Sep-2010::11:57:03 === > SSL: 1060: error:{error, > {asn1, > {{case_clause,19}, > [{'OTP-PUB-KEY', > > check_and_convert_restricted_string,5}, > {'OTP-PUB-KEY',decode,2}, > > {pubkey_cert_records,transform,2}, > {lists,map,2}, > {lists,map,2}, > > {pubkey_cert_records,transform,2}, > > {pubkey_cert_records,decode_tbs,1}, > > {pubkey_cert_records,decode_cert,2}]}}} > /home/fdmanana/tmp/ibrowse-test/ca-certificates.crt > [] > > ** exception error: no match of right hand side value > {error,ecacertfile} > > > > > Yes I get this too, it seems to be that one of the > certificates in > the file > has a field that is utf8-encoded but the asn-1-spec says > that it > should > be a "printableString". I do not know if openssl tries to > decode > it, it might > not until it is used, and it might not be. Erlang ssl > caches all > cert in the ca-file. > I have now made new ssl more tolerant so that it > will ignore such ca-certs, that does not follow the spec. > I have > pushed the change to > the ia/ssl-asn1-spec-dss-params branch. > > > And btw, with the old ssl implementation, using a ssl > socket > in {active, > once} mode, I receive very often an error like this: > > [Thu, 16 Sep 2010 00:10:34 GMT] [error] [<0.604.0>] ** > Generic > server > <0.604.0> terminating > ** Last message in was {tcp,#Port<0.2288>, > > > <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>} > ** When Server state == > {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false, > [{mode,binary}, > {nodelay,true}, > {active,once}, > {packet,0}, > {ip,{0,0,0,0}}, > {verify,0}, > {depth,1}], > {sslsocket,11,<0.604.0>}, > > #Port<0.2288>,nil,open,false,false} > > > The data, third argument of the tuple, is what is > supposed to > be. However > the ssl module trows that exception (since it was > expecting to > receive only > messages like {ssl, Socket, Data}). Is this a known issue? > > > > > Humm ... not that I know of. We are aiming to remove the old > ssl-implementation as soon as the new one is compleate > enough and > in first hand we do not fix things in the old implementation. > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org > mailing list. > > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > > > > > > > -- > Filipe David Manana, > fdmanana@REDACTED > >, > fdmanana@REDACTED > > > > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > > > > > -- > Filipe David Manana, > fdmanana@REDACTED , fdmanana@REDACTED > > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > From ingela@REDACTED Wed Sep 22 15:11:54 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 22 Sep 2010 15:11:54 +0200 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: <4C99B4D7.5020307@erix.ericsson.se> References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> <4C989FFC.9060806@erix.ericsson.se> <4C98CA31.4010301@erix.ericsson.se> <4C99B4D7.5020307@erix.ericsson.se> Message-ID: <4C9A009A.4060803@erix.ericsson.se> Hi again, something went wrong with the branch please look at the branch ia/ssl-and-public_key/backwards-compatibility/OTP-8858 instead. Regards Ingela Erlang/OTP team - Ericsson AB Ingela Anderton Andin wrote: > Hi again! > > Well ok, first I would like you to provide the option verify_fun: > > FunAndState = {fun(_,{bad_cert, _} = Reason, _) -> > io:format("Reason: ~p~n", [Reason]), > {fail, Reason}; > (_,{extension, _}, UserState) -> > {unknown, UserState}; > (_, valid, UserState) -> > {valid, UserState} > end, []}, > > add option: > {verify_fun, FunAndState} > > So we can try to find out why it does not like the cert. > > By the way we decided to shorten the INFO report if you would like to > run the latest ssl it is now > on the branch ia/ssl/public_key/backwards-compatibility/OTP-8858. > > Regards Ingela Erlang/OTP team - Ericsson AB > > Filipe David Manana wrote: >> On Tue, Sep 21, 2010 at 4:07 PM, Ingela Anderton Andin >> > wrote: >> >> Hi! >> >> Yes you could, it is a INFO report a warning that that particular >> CA cert is ignored as we could not decode it. >> But you get another handshake error. What options do you connect >> with ? >> >> >> This is an excerpt of my testing code: >> >> Options = [ >> {ssl_imp, new}, >> binary, >> {nodelay, true}, >> {active, false}, >> {verify, verify_peer}, >> {depth, 3}, >> {cacertfile, "/etc/ssl/certs/ca-certificates.crt"} >> ], >> {ok, S} = ssl:connect(?HOST, 443, Options), >> ok = ssl:send(S, Body), >> loop(S), >> ssl:close(S). >> >> loop(S) -> >> ssl:setopts(S, [{active, once}]), >> receive >> {ssl, S, Data} -> >> io:format("received data: ~p~n", [Data]), >> loop(S); >> {ssl_closed, S} -> >> io:format("socket closed", []); >> {ssl_error, S, Error} -> >> io:format("socket error: ~p~n", [Error]) >> end. >> >> >> Once again, thanks for looking into this. >> >> >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> Filipe David Manana wrote: >> >> Ingela, >> >> After pulling your last commit, things advance a bit more, but >> still not able to open the CAs file: >> >> =INFO REPORT==== 21-Sep-2010::14:35:58 === >> SSL WARNING: Ignoring CA cert: >> <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, >> >> 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, >> >> 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, >> >> 156,82,75,84,82,85,83,84,32,69,108,101,107, >> >> 116,114,111,110,105,107,32,83,101,114,116,105, >> >> 102,105,107,97,32,72,105,122,109,101,116,32, >> >> 83,97,196,159,108,97,121,196,177,99,196,177, >> >> 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, >> >> 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, >> >> 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, >> >> 48,48,53,32,84,195,156,82,75,84,82,85,83,84, >> >> 32,66,105,108,103,105,32,196,176,108,101,116, >> >> 105,197,159,105,109,32,118,101,32,66,105,108, >> >> 105,197,159,105,109,32,71,195,188,118,101,110, >> >> 108,105,196,159,105,32,72,105,122,109,101,116, >> >> 108,101,114,105,32,65,46,197,158,46,48,30,23, >> >> 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, >> >> 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, >> >> 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, >> >> 156,82,75,84,82,85,83,84,32,69,108,101,107, >> >> 116,114,111,110,105,107,32,83,101,114,116,105, >> >> 102,105,107,97,32,72,105,122,109,101,116,32, >> >> 83,97,196,159,108,97,121,196,177,99,196,177, >> >> 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, >> >> 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, >> >> 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, >> >> 48,48,53,32,84,195,156,82,75,84,82,85,83,84, >> >> 32,66,105,108,103,105,32,196,176,108,101,116, >> >> 105,197,159,105,109,32,118,101,32,66,105,108, >> >> 105,197,159,105,109,32,71,195,188,118,101,110, >> >> 108,105,196,159,105,32,72,105,122,109,101,116, >> >> 108,101,114,105,32,65,46,197,158,46,48,130,1, >> >> 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, >> >> 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, >> >> 214,99,3,216,28,95,221,210,123,93,242,12,96, >> >> 97,91,107,59,116,43,120,13,125,69,189,34,116, >> >> 232,140,3,193,198,17,42,61,149,188,169,148, >> >> 176,187,145,151,200,105,124,132,197,180,145, >> >> 108,108,19,106,164,85,173,164,133,232,149,126, >> >> 179,0,175,0,194,5,24,245,112,157,54,139,174, >> >> 203,228,27,129,127,147,136,251,106,85,187,125, >> >> 133,146,206,186,88,159,219,50,197,189,93,239, >> >> 34,74,47,65,7,126,73,97,179,134,236,78,166,65, >> >> 110,132,188,3,236,245,59,28,200,31,194,238, >> >> 168,238,234,18,74,141,20,207,243,10,224,80,57, >> >> 249,8,53,248,17,89,173,231,34,234,75,202,20,6, >> >> 222,66,186,178,153,243,45,84,136,16,6,234,225, >> >> 26,62,61,103,31,251,206,251,124,130,232,17,93, >> >> 74,193,185,20,234,84,217,102,155,124,137,125, >> >> 4,154,98,201,233,82,60,158,156,239,210,245,38, >> >> 228,230,229,24,124,139,110,223,108,204,120,91, >> >> 79,114,178,203,92,63,140,5,141,209,76,140,173, >> >> 146,199,225,120,127,101,108,73,6,80,44,158,50, >> >> 194,215,74,198,117,138,89,78,117,111,71,94, >> >> 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, >> >> 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, >> >> 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, >> >> 128,89,33,164,252,161,21,76,32,246,212,95,218, >> >> 3,36,252,207,144,26,244,33,10,154,238,58,177, >> >> 106,239,239,248,96,209,76,54,102,69,29,243, >> >> 102,2,116,4,123,146,48,168,222,10,118,15,239, >> >> 149,110,189,201,55,230,26,13,172,137,72,91, >> >> 204,131,54,194,245,70,92,89,130,86,180,213, >> >> 254,35,180,216,84,28,68,171,196,167,229,20, >> >> 206,60,65,97,124,67,230,205,196,129,9,139,36, >> >> 251,84,37,214,22,168,150,12,103,7,111,179,80, >> >> 71,227,28,36,40,221,42,152,164,97,254,219,234, >> >> 18,55,188,1,26,52,133,189,110,79,231,145,114, >> >> 7,68,133,30,88,202,84,68,221,247,172,185,203, >> >> 137,33,114,219,143,192,105,41,151,42,163,174, >> >> 24,35,151,28,65,42,139,124,42,193,124,144,232, >> >> 169,40,192,211,145,198,173,40,135,64,104,181, >> >> 255,236,167,210,211,56,24,156,211,125,105,93, >> >> 240,198,165,30,36,27,163,71,252,105,7,104,231, >> >> 228,154,180,237,15,161,135,135,2,206,135,210, >> >> 72,78,225,188,255,203,241,114,146,68,100,3,37, >> >> 234,222,91,110,159,201,242,78,172,221,199>> >> Due to decoding error:{badmatch, >> {error, >> {asn1, >> {{case_clause,19}, >> [{'OTP-PUB-KEY', >> >> check_and_convert_restricted_string,5}, >> {'OTP-PUB-KEY',decode,2}, >> {pubkey_cert_records,transform,2}, >> {lists,map,2}, >> {lists,map,2}, >> {pubkey_cert_records,transform,2}, >> {pubkey_cert_records,decode_tbs,1}, >> >> {pubkey_cert_records,decode_cert,1}]}}}} >> >> >> =ERROR REPORT==== 21-Sep-2010::14:35:58 === >> SSL: certify_certificate: ./ssl_handshake.erl:584:Fatal error: >> handshake failure >> ** exception error: no match of right hand side value >> {error,esslconnect} >> in function ssl_test:test/0 >> >> >> cheers >> >> On Tue, Sep 21, 2010 at 1:07 PM, Ingela Anderton Andin >> >> > >> wrote: >> >> Hi! >> >> Filipe David Manana wrote: >> >> On Mon, Sep 20, 2010 at 2:47 PM, Ingela Anderton Andin < >> ingela@REDACTED >> >> > >> wrote: >> >> So I definitely consider this a >> regression :( >> The weird thing is that I can use this >> certificates >> file with the old ssl >> implementation (default on R13 and R12 releases) on >> R13B03 >> and R13B04 at >> least. >> Well the thing is that the old ssl-implementation >> only is >> an erlang-glue >> that leaves the most things up to the underlaying >> openssl >> implementation, >> but the new ssl >> only uses openssl crypto library and takes care >> the ssl >> protocol >> fsm-machinery and certificate handling on its >> own. This >> makes many things >> much easier to implement >> and removes the bottleneck enforced by the glue, >> and also >> lessens the >> required resource allocation. Of course this may >> cause new >> bugs occasionally >> and we fix them >> as fast as we can. >> If you want to try out the latest changes to fix the >> DSS-Params bug you can >> get the branch ia/ssl-asn1-spec-dss-params at my >> github >> account >> git@REDACTED:IngelaAndin/otp.git >> >> >> Hi, >> >> Ingela, I tried your git branch >> ssl-asn1-spec-dss-params but >> unfortunatelly >> I still get an exception: >> >> =ERROR REPORT==== 21-Sep-2010::11:57:03 === >> SSL: 1060: error:{error, >> {asn1, >> {{case_clause,19}, >> [{'OTP-PUB-KEY', >> >> check_and_convert_restricted_string,5}, >> {'OTP-PUB-KEY',decode,2}, >> >> {pubkey_cert_records,transform,2}, >> {lists,map,2}, >> {lists,map,2}, >> >> {pubkey_cert_records,transform,2}, >> >> {pubkey_cert_records,decode_tbs,1}, >> >> {pubkey_cert_records,decode_cert,2}]}}} >> /home/fdmanana/tmp/ibrowse-test/ca-certificates.crt >> [] >> >> ** exception error: no match of right hand side value >> {error,ecacertfile} >> >> >> >> Yes I get this too, it seems to be that one of the >> certificates in >> the file >> has a field that is utf8-encoded but the asn-1-spec says >> that it >> should >> be a "printableString". I do not know if openssl tries to >> decode >> it, it might >> not until it is used, and it might not be. Erlang ssl >> caches all >> cert in the ca-file. >> I have now made new ssl more tolerant so that it >> will ignore such ca-certs, that does not follow the spec. >> I have >> pushed the change to >> the ia/ssl-asn1-spec-dss-params branch. >> >> >> And btw, with the old ssl implementation, using a ssl >> socket >> in {active, >> once} mode, I receive very often an error like this: >> >> [Thu, 16 Sep 2010 00:10:34 GMT] [error] [<0.604.0>] ** >> Generic >> server >> <0.604.0> terminating >> ** Last message in was {tcp,#Port<0.2288>, >> >> >> <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>} >> >> ** When Server state == >> {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false, >> [{mode,binary}, >> {nodelay,true}, >> {active,once}, >> {packet,0}, >> {ip,{0,0,0,0}}, >> {verify,0}, >> {depth,1}], >> {sslsocket,11,<0.604.0>}, >> >> #Port<0.2288>,nil,open,false,false} >> >> >> The data, third argument of the tuple, is what is >> supposed to >> be. However >> the ssl module trows that exception (since it was >> expecting to >> receive only >> messages like {ssl, Socket, Data}). Is this a known >> issue? >> >> >> >> Humm ... not that I know of. We are aiming to remove the old >> ssl-implementation as soon as the new one is compleate >> enough and >> in first hand we do not fix things in the old implementation. >> >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> >> >> >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org >> mailing list. >> >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> >> > > >> >> >> >> >> -- Filipe David Manana, >> fdmanana@REDACTED >> >, >> fdmanana@REDACTED >> > >> >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." >> >> >> >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> >> >> >> >> >> -- >> Filipe David Manana, >> fdmanana@REDACTED , fdmanana@REDACTED >> >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." >> > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > From fdmanana@REDACTED Wed Sep 22 17:11:44 2010 From: fdmanana@REDACTED (Filipe David Manana) Date: Wed, 22 Sep 2010 16:11:44 +0100 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: <4C9A009A.4060803@erix.ericsson.se> References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> <4C989FFC.9060806@erix.ericsson.se> <4C98CA31.4010301@erix.ericsson.se> <4C99B4D7.5020307@erix.ericsson.se> <4C9A009A.4060803@erix.ericsson.se> Message-ID: Ingela, some progress with that branch: 2> ssl_test:test(). =INFO REPORT==== 22-Sep-2010::16:10:13 === SSL WARNING: Ignoring CA cert: <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, 156,82,75,84,82,85,83,84,32,69,108,101,107, 116,114,111,110,105,107,32,83,101,114,116,105, 102,105,107,97,32,72,105,122,109,101,116,32, 83,97,196,159,108,97,121,196,177,99,196,177, 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, 48,48,53,32,84,195,156,82,75,84,82,85,83,84, 32,66,105,108,103,105,32,196,176,108,101,116, 105,197,159,105,109,32,118,101,32,66,105,108, 105,197,159,105,109,32,71,195,188,118,101,110, 108,105,196,159,105,32,72,105,122,109,101,116, 108,101,114,105,32,65,46,197,158,46,48,30,23, 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, 156,82,75,84,82,85,83,84,32,69,108,101,107, 116,114,111,110,105,107,32,83,101,114,116,105, 102,105,107,97,32,72,105,122,109,101,116,32, 83,97,196,159,108,97,121,196,177,99,196,177, 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, 48,48,53,32,84,195,156,82,75,84,82,85,83,84, 32,66,105,108,103,105,32,196,176,108,101,116, 105,197,159,105,109,32,118,101,32,66,105,108, 105,197,159,105,109,32,71,195,188,118,101,110, 108,105,196,159,105,32,72,105,122,109,101,116, 108,101,114,105,32,65,46,197,158,46,48,130,1, 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, 214,99,3,216,28,95,221,210,123,93,242,12,96, 97,91,107,59,116,43,120,13,125,69,189,34,116, 232,140,3,193,198,17,42,61,149,188,169,148, 176,187,145,151,200,105,124,132,197,180,145, 108,108,19,106,164,85,173,164,133,232,149,126, 179,0,175,0,194,5,24,245,112,157,54,139,174, 203,228,27,129,127,147,136,251,106,85,187,125, 133,146,206,186,88,159,219,50,197,189,93,239, 34,74,47,65,7,126,73,97,179,134,236,78,166,65, 110,132,188,3,236,245,59,28,200,31,194,238, 168,238,234,18,74,141,20,207,243,10,224,80,57, 249,8,53,248,17,89,173,231,34,234,75,202,20,6, 222,66,186,178,153,243,45,84,136,16,6,234,225, 26,62,61,103,31,251,206,251,124,130,232,17,93, 74,193,185,20,234,84,217,102,155,124,137,125, 4,154,98,201,233,82,60,158,156,239,210,245,38, 228,230,229,24,124,139,110,223,108,204,120,91, 79,114,178,203,92,63,140,5,141,209,76,140,173, 146,199,225,120,127,101,108,73,6,80,44,158,50, 194,215,74,198,117,138,89,78,117,111,71,94, 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, 128,89,33,164,252,161,21,76,32,246,212,95,218, 3,36,252,207,144,26,244,33,10,154,238,58,177, 106,239,239,248,96,209,76,54,102,69,29,243, 102,2,116,4,123,146,48,168,222,10,118,15,239, 149,110,189,201,55,230,26,13,172,137,72,91, 204,131,54,194,245,70,92,89,130,86,180,213, 254,35,180,216,84,28,68,171,196,167,229,20, 206,60,65,97,124,67,230,205,196,129,9,139,36, 251,84,37,214,22,168,150,12,103,7,111,179,80, 71,227,28,36,40,221,42,152,164,97,254,219,234, 18,55,188,1,26,52,133,189,110,79,231,145,114, 7,68,133,30,88,202,84,68,221,247,172,185,203, 137,33,114,219,143,192,105,41,151,42,163,174, 24,35,151,28,65,42,139,124,42,193,124,144,232, 169,40,192,211,145,198,173,40,135,64,104,181, 255,236,167,210,211,56,24,156,211,125,105,93, 240,198,165,30,36,27,163,71,252,105,7,104,231, 228,154,180,237,15,161,135,135,2,206,135,210, 72,78,225,188,255,203,241,114,146,68,100,3,37, 234,222,91,110,159,201,242,78,172,221,199>> Due to decoding error:{badmatch, {error, {asn1, {{case_clause,19}, [{'OTP-PUB-KEY', check_and_convert_restricted_string,5}, {'OTP-PUB-KEY',decode,2}, {pubkey_cert_records,transform,2}, {lists,map,2}, {lists,map,2}, {pubkey_cert_records,transform,2}, {pubkey_cert_records,decode_tbs,1}, {pubkey_cert_records,decode_cert,1}]}}}} Reason: {bad_cert,missing_basic_constraint} =ERROR REPORT==== 22-Sep-2010::16:10:13 === SSL: certify_certificate: ./ssl_handshake.erl:586:Fatal error: handshake failure ** exception error: no match of right hand side value {error,esslconnect} in function ssl_test:test/0 3> Does this error rings a bell? cheers On Wed, Sep 22, 2010 at 2:11 PM, Ingela Anderton Andin < ingela@REDACTED> wrote: > Hi again, something went wrong with the branch please look at the > branch ia/ssl-and-public_key/backwards-compatibility/OTP-8858 instead. > > > Regards Ingela Erlang/OTP team - Ericsson AB > > Ingela Anderton Andin wrote: > >> Hi again! >> >> Well ok, first I would like you to provide the option verify_fun: >> >> FunAndState = {fun(_,{bad_cert, _} = Reason, _) -> >> io:format("Reason: ~p~n", [Reason]), >> {fail, Reason}; >> (_,{extension, _}, UserState) -> >> {unknown, UserState}; >> (_, valid, UserState) -> >> {valid, UserState} >> end, []}, >> >> add option: >> {verify_fun, FunAndState} >> >> So we can try to find out why it does not like the cert. >> >> By the way we decided to shorten the INFO report if you would like to run >> the latest ssl it is now >> on the branch ia/ssl/public_key/backwards-compatibility/OTP-8858. >> >> > > > > Regards Ingela Erlang/OTP team - Ericsson AB >> >> Filipe David Manana wrote: >> >>> On Tue, Sep 21, 2010 at 4:07 PM, Ingela Anderton Andin < >>> ingela@REDACTED > wrote: >>> >>> Hi! >>> >>> Yes you could, it is a INFO report a warning that that particular >>> CA cert is ignored as we could not decode it. >>> But you get another handshake error. What options do you connect >>> with ? >>> >>> >>> This is an excerpt of my testing code: >>> >>> Options = [ >>> {ssl_imp, new}, >>> binary, >>> {nodelay, true}, >>> {active, false}, >>> {verify, verify_peer}, >>> {depth, 3}, >>> {cacertfile, "/etc/ssl/certs/ca-certificates.crt"} >>> ], >>> {ok, S} = ssl:connect(?HOST, 443, Options), >>> ok = ssl:send(S, Body), >>> loop(S), >>> ssl:close(S). >>> >>> loop(S) -> >>> ssl:setopts(S, [{active, once}]), >>> receive >>> {ssl, S, Data} -> >>> io:format("received data: ~p~n", [Data]), >>> loop(S); >>> {ssl_closed, S} -> >>> io:format("socket closed", []); >>> {ssl_error, S, Error} -> >>> io:format("socket error: ~p~n", [Error]) >>> end. >>> >>> Once again, thanks for looking into this. >>> >>> >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> Filipe David Manana wrote: >>> >>> Ingela, >>> >>> After pulling your last commit, things advance a bit more, but >>> still not able to open the CAs file: >>> >>> =INFO REPORT==== 21-Sep-2010::14:35:58 === >>> SSL WARNING: Ignoring CA cert: >>> <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, >>> >>> 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, >>> >>> 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, >>> >>> 156,82,75,84,82,85,83,84,32,69,108,101,107, >>> >>> 116,114,111,110,105,107,32,83,101,114,116,105, >>> >>> 102,105,107,97,32,72,105,122,109,101,116,32, >>> >>> 83,97,196,159,108,97,121,196,177,99,196,177, >>> >>> 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, >>> >>> 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, >>> >>> 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, >>> >>> 48,48,53,32,84,195,156,82,75,84,82,85,83,84, >>> >>> 32,66,105,108,103,105,32,196,176,108,101,116, >>> >>> 105,197,159,105,109,32,118,101,32,66,105,108, >>> >>> 105,197,159,105,109,32,71,195,188,118,101,110, >>> >>> 108,105,196,159,105,32,72,105,122,109,101,116, >>> >>> 108,101,114,105,32,65,46,197,158,46,48,30,23, >>> >>> 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, >>> >>> 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, >>> >>> 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, >>> >>> 156,82,75,84,82,85,83,84,32,69,108,101,107, >>> >>> 116,114,111,110,105,107,32,83,101,114,116,105, >>> >>> 102,105,107,97,32,72,105,122,109,101,116,32, >>> >>> 83,97,196,159,108,97,121,196,177,99,196,177, >>> >>> 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, >>> >>> 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, >>> >>> 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, >>> >>> 48,48,53,32,84,195,156,82,75,84,82,85,83,84, >>> >>> 32,66,105,108,103,105,32,196,176,108,101,116, >>> >>> 105,197,159,105,109,32,118,101,32,66,105,108, >>> >>> 105,197,159,105,109,32,71,195,188,118,101,110, >>> >>> 108,105,196,159,105,32,72,105,122,109,101,116, >>> >>> 108,101,114,105,32,65,46,197,158,46,48,130,1, >>> >>> 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, >>> >>> 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, >>> >>> 214,99,3,216,28,95,221,210,123,93,242,12,96, >>> >>> 97,91,107,59,116,43,120,13,125,69,189,34,116, >>> >>> 232,140,3,193,198,17,42,61,149,188,169,148, >>> >>> 176,187,145,151,200,105,124,132,197,180,145, >>> >>> 108,108,19,106,164,85,173,164,133,232,149,126, >>> >>> 179,0,175,0,194,5,24,245,112,157,54,139,174, >>> >>> 203,228,27,129,127,147,136,251,106,85,187,125, >>> >>> 133,146,206,186,88,159,219,50,197,189,93,239, >>> >>> 34,74,47,65,7,126,73,97,179,134,236,78,166,65, >>> >>> 110,132,188,3,236,245,59,28,200,31,194,238, >>> >>> 168,238,234,18,74,141,20,207,243,10,224,80,57, >>> >>> 249,8,53,248,17,89,173,231,34,234,75,202,20,6, >>> >>> 222,66,186,178,153,243,45,84,136,16,6,234,225, >>> >>> 26,62,61,103,31,251,206,251,124,130,232,17,93, >>> >>> 74,193,185,20,234,84,217,102,155,124,137,125, >>> >>> 4,154,98,201,233,82,60,158,156,239,210,245,38, >>> >>> 228,230,229,24,124,139,110,223,108,204,120,91, >>> >>> 79,114,178,203,92,63,140,5,141,209,76,140,173, >>> >>> 146,199,225,120,127,101,108,73,6,80,44,158,50, >>> >>> 194,215,74,198,117,138,89,78,117,111,71,94, >>> >>> 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, >>> >>> 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, >>> >>> 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, >>> >>> 128,89,33,164,252,161,21,76,32,246,212,95,218, >>> >>> 3,36,252,207,144,26,244,33,10,154,238,58,177, >>> >>> 106,239,239,248,96,209,76,54,102,69,29,243, >>> >>> 102,2,116,4,123,146,48,168,222,10,118,15,239, >>> >>> 149,110,189,201,55,230,26,13,172,137,72,91, >>> >>> 204,131,54,194,245,70,92,89,130,86,180,213, >>> >>> 254,35,180,216,84,28,68,171,196,167,229,20, >>> >>> 206,60,65,97,124,67,230,205,196,129,9,139,36, >>> >>> 251,84,37,214,22,168,150,12,103,7,111,179,80, >>> >>> 71,227,28,36,40,221,42,152,164,97,254,219,234, >>> >>> 18,55,188,1,26,52,133,189,110,79,231,145,114, >>> >>> 7,68,133,30,88,202,84,68,221,247,172,185,203, >>> >>> 137,33,114,219,143,192,105,41,151,42,163,174, >>> >>> 24,35,151,28,65,42,139,124,42,193,124,144,232, >>> >>> 169,40,192,211,145,198,173,40,135,64,104,181, >>> >>> 255,236,167,210,211,56,24,156,211,125,105,93, >>> >>> 240,198,165,30,36,27,163,71,252,105,7,104,231, >>> >>> 228,154,180,237,15,161,135,135,2,206,135,210, >>> >>> 72,78,225,188,255,203,241,114,146,68,100,3,37, >>> >>> 234,222,91,110,159,201,242,78,172,221,199>> >>> Due to decoding error:{badmatch, >>> {error, >>> {asn1, >>> {{case_clause,19}, >>> [{'OTP-PUB-KEY', >>> >>> check_and_convert_restricted_string,5}, >>> {'OTP-PUB-KEY',decode,2}, >>> {pubkey_cert_records,transform,2}, >>> {lists,map,2}, >>> {lists,map,2}, >>> {pubkey_cert_records,transform,2}, >>> {pubkey_cert_records,decode_tbs,1}, >>> >>> {pubkey_cert_records,decode_cert,1}]}}}} >>> >>> >>> =ERROR REPORT==== 21-Sep-2010::14:35:58 === >>> SSL: certify_certificate: ./ssl_handshake.erl:584:Fatal error: >>> handshake failure >>> ** exception error: no match of right hand side value >>> {error,esslconnect} >>> in function ssl_test:test/0 >>> >>> >>> cheers >>> >>> On Tue, Sep 21, 2010 at 1:07 PM, Ingela Anderton Andin >>> >>> >> >> wrote: >>> >>> Hi! >>> >>> Filipe David Manana wrote: >>> >>> On Mon, Sep 20, 2010 at 2:47 PM, Ingela Anderton Andin < >>> ingela@REDACTED >>> >>> >> >> wrote: >>> >>> So I definitely consider this a >>> regression :( >>> The weird thing is that I can use this certificates >>> file with the old ssl >>> implementation (default on R13 and R12 releases) on >>> R13B03 >>> and R13B04 at >>> least. >>> Well the thing is that the old ssl-implementation >>> only is >>> an erlang-glue >>> that leaves the most things up to the underlaying >>> openssl >>> implementation, >>> but the new ssl >>> only uses openssl crypto library and takes care the ssl >>> protocol >>> fsm-machinery and certificate handling on its >>> own. This >>> makes many things >>> much easier to implement >>> and removes the bottleneck enforced by the glue, >>> and also >>> lessens the >>> required resource allocation. Of course this may >>> cause new >>> bugs occasionally >>> and we fix them >>> as fast as we can. >>> If you want to try out the latest changes to fix the >>> DSS-Params bug you can >>> get the branch ia/ssl-asn1-spec-dss-params at my github >>> account >>> git@REDACTED:IngelaAndin/otp.git >>> >>> Hi, >>> >>> Ingela, I tried your git branch >>> ssl-asn1-spec-dss-params but >>> unfortunatelly >>> I still get an exception: >>> >>> =ERROR REPORT==== 21-Sep-2010::11:57:03 === >>> SSL: 1060: error:{error, >>> {asn1, >>> {{case_clause,19}, >>> [{'OTP-PUB-KEY', >>> >>> check_and_convert_restricted_string,5}, >>> {'OTP-PUB-KEY',decode,2}, >>> >>> {pubkey_cert_records,transform,2}, >>> {lists,map,2}, >>> {lists,map,2}, >>> >>> {pubkey_cert_records,transform,2}, >>> >>> {pubkey_cert_records,decode_tbs,1}, >>> >>> {pubkey_cert_records,decode_cert,2}]}}} >>> /home/fdmanana/tmp/ibrowse-test/ca-certificates.crt >>> [] >>> >>> ** exception error: no match of right hand side value >>> {error,ecacertfile} >>> >>> >>> Yes I get this too, it seems to be that one of >>> the >>> certificates in >>> the file >>> has a field that is utf8-encoded but the asn-1-spec says >>> that it >>> should >>> be a "printableString". I do not know if openssl tries to >>> decode >>> it, it might >>> not until it is used, and it might not be. Erlang ssl >>> caches all >>> cert in the ca-file. >>> I have now made new ssl more tolerant so that it >>> will ignore such ca-certs, that does not follow the spec. >>> I have >>> pushed the change to >>> the ia/ssl-asn1-spec-dss-params branch. >>> >>> >>> And btw, with the old ssl implementation, using a ssl >>> socket >>> in {active, >>> once} mode, I receive very often an error like this: >>> >>> [Thu, 16 Sep 2010 00:10:34 GMT] [error] [<0.604.0>] ** >>> Generic >>> server >>> <0.604.0> terminating >>> ** Last message in was {tcp,#Port<0.2288>, >>> >>> >>> <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>} >>> >>> ** When Server state == >>> {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false, >>> [{mode,binary}, >>> {nodelay,true}, >>> {active,once}, >>> {packet,0}, >>> {ip,{0,0,0,0}}, >>> {verify,0}, >>> {depth,1}], >>> {sslsocket,11,<0.604.0>}, >>> >>> #Port<0.2288>,nil,open,false,false} >>> >>> >>> The data, third argument of the tuple, is what is >>> supposed to >>> be. However >>> the ssl module trows that exception (since it was >>> expecting to >>> receive only >>> messages like {ssl, Socket, Data}). Is this a known issue? >>> >>> >>> Humm ... not that I know of. We are aiming to >>> remove the old >>> ssl-implementation as soon as the new one is compleate >>> enough and >>> in first hand we do not fix things in the old implementation. >>> >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> >>> >>> >>> >>> ________________________________________________________________ >>> erlang-bugs (at) erlang.org >>> mailing list. >>> >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >>> >>> >> > >>> >>> >>> >>> >>> -- Filipe David Manana, >>> fdmanana@REDACTED >>> >, >>> fdmanana@REDACTED >>> > >>> >>> >>> "Reasonable men adapt themselves to the world. >>> Unreasonable men adapt the world to themselves. >>> That's why all progress depends on unreasonable men." >>> >>> >>> >>> >>> ________________________________________________________________ >>> erlang-bugs (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >>> >>> >>> >>> >>> >>> -- >>> Filipe David Manana, >>> fdmanana@REDACTED , fdmanana@REDACTED>> fdmanana@REDACTED> >>> >>> "Reasonable men adapt themselves to the world. >>> Unreasonable men adapt the world to themselves. >>> That's why all progress depends on unreasonable men." >>> >>> >> >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> >> >> > > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From tuncer.ayaz@REDACTED Wed Sep 22 23:32:02 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 22 Sep 2010 23:32:02 +0200 Subject: beam.smp (enable-native-libs) hang In-Reply-To: References: Message-ID: On Wed, Sep 8, 2010 at 2:02 PM, Tuncer Ayaz wrote: > Erlang version: a78b39a0e9ff2cfd13273ab077dc852d70565647 > > Build Options: --enable-native-libs (HiPE is enabled automatically) > > Arch: > ? ? linux 2.6.35 x86_32, glibc 2.12.1 > ? ? darwin 10.6.4 x86_64 > > Symptom: beam.smp hangs/doesn't terminate > > Steps to reproduce: > > There are two known ways to reproduce the issue and the simplest is: > > $ hg clone http://bitbucket.org/basho/rebar > $ cd rebar > $ make > [...] > Recompile: src/rebar_xref > ^Cmake: *** [all] Interrupt > > Compiling src/rebar_xref.erl hangs indefinitely at 100% cpu load. > > You can also reproduce the hang running 'rebar compile' in a project > that makes use of it. > > A shared trait is running an escript. > Paul Guyot's patch [erlang-patches] [PATCH] Fix hang when calling functions in a module with an on_load attribute from a native module seems to fix the issue. From ingela@REDACTED Thu Sep 23 11:19:04 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Thu, 23 Sep 2010 11:19:04 +0200 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> <4C989FFC.9060806@erix.ericsson.se> <4C98CA31.4010301@erix.ericsson.se> <4C99B4D7.5020307@erix.ericsson.se> <4C9A009A.4060803@erix.ericsson.se> Message-ID: <4C9B1B88.4020609@erix.ericsson.se> Hi! Possible if your certificate is an old one the extension validation could come up with the result missing_basic_constraint when it should not, and in that case the following patch should help. diff --git a/lib/public_key/src/pubkey_cert.erl b/lib/public_key/src/pubkey_cert.erl index 2335a4e..85d4e29 100644 --- a/lib/public_key/src/pubkey_cert.erl +++ b/lib/public_key/src/pubkey_cert.erl @@ -223,10 +223,15 @@ validate_revoked_status(_OtpCert, UserState, _VerifyFun) -> %%-------------------------------------------------------------------- validate_extensions(OtpCert, ValidationState, UserState, VerifyFun) -> TBSCert = OtpCert#'OTPCertificate'.tbsCertificate, - Extensions = TBSCert#'OTPTBSCertificate'.extensions, - validate_extensions(OtpCert, Extensions, ValidationState, no_basic_constraint, - is_self_signed(OtpCert), UserState, VerifyFun). - + case TBSCert#'OTPTBSCertificate'.version of + N when N >= 3 -> + Extensions = TBSCert#'OTPTBSCertificate'.extensions, + validate_extensions(OtpCert, Extensions, + ValidationState, no_basic_constraint, + is_self_signed(OtpCert), UserState, VerifyFun); + _ -> %% Extensions not present in versions 1 & 2 + {ValidationState, UserState} + end. %%-------------------------------------------------------------------- -spec normalize_general_name({rdnSequence, term()}) -> {rdnSequence, term()}. %% Can this be the problem? Regards Ingela Erlang/OTP Team - Ericsson AB Filipe David Manana wrote: > Ingela, some progress with that branch: > > 2> ssl_test:test(). > > =INFO REPORT==== 22-Sep-2010::16:10:13 === > SSL WARNING: Ignoring CA cert: > <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, > > 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, > > 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, > > 156,82,75,84,82,85,83,84,32,69,108,101,107, > > 116,114,111,110,105,107,32,83,101,114,116,105, > > 102,105,107,97,32,72,105,122,109,101,116,32, > > 83,97,196,159,108,97,121,196,177,99,196,177, > > 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, > > 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, > > 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, > > 48,48,53,32,84,195,156,82,75,84,82,85,83,84, > > 32,66,105,108,103,105,32,196,176,108,101,116, > > 105,197,159,105,109,32,118,101,32,66,105,108, > > 105,197,159,105,109,32,71,195,188,118,101,110, > > 108,105,196,159,105,32,72,105,122,109,101,116, > > 108,101,114,105,32,65,46,197,158,46,48,30,23, > > 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, > > 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, > > 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, > > 156,82,75,84,82,85,83,84,32,69,108,101,107, > > 116,114,111,110,105,107,32,83,101,114,116,105, > > 102,105,107,97,32,72,105,122,109,101,116,32, > > 83,97,196,159,108,97,121,196,177,99,196,177, > > 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, > > 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, > > 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, > > 48,48,53,32,84,195,156,82,75,84,82,85,83,84, > > 32,66,105,108,103,105,32,196,176,108,101,116, > > 105,197,159,105,109,32,118,101,32,66,105,108, > > 105,197,159,105,109,32,71,195,188,118,101,110, > > 108,105,196,159,105,32,72,105,122,109,101,116, > > 108,101,114,105,32,65,46,197,158,46,48,130,1, > > 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, > > 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, > > 214,99,3,216,28,95,221,210,123,93,242,12,96, > > 97,91,107,59,116,43,120,13,125,69,189,34,116, > > 232,140,3,193,198,17,42,61,149,188,169,148, > > 176,187,145,151,200,105,124,132,197,180,145, > > 108,108,19,106,164,85,173,164,133,232,149,126, > > 179,0,175,0,194,5,24,245,112,157,54,139,174, > > 203,228,27,129,127,147,136,251,106,85,187,125, > > 133,146,206,186,88,159,219,50,197,189,93,239, > > 34,74,47,65,7,126,73,97,179,134,236,78,166,65, > > 110,132,188,3,236,245,59,28,200,31,194,238, > > 168,238,234,18,74,141,20,207,243,10,224,80,57, > > 249,8,53,248,17,89,173,231,34,234,75,202,20,6, > > 222,66,186,178,153,243,45,84,136,16,6,234,225, > > 26,62,61,103,31,251,206,251,124,130,232,17,93, > > 74,193,185,20,234,84,217,102,155,124,137,125, > > 4,154,98,201,233,82,60,158,156,239,210,245,38, > > 228,230,229,24,124,139,110,223,108,204,120,91, > > 79,114,178,203,92,63,140,5,141,209,76,140,173, > > 146,199,225,120,127,101,108,73,6,80,44,158,50, > > 194,215,74,198,117,138,89,78,117,111,71,94, > > 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, > > 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, > > 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, > > 128,89,33,164,252,161,21,76,32,246,212,95,218, > > 3,36,252,207,144,26,244,33,10,154,238,58,177, > > 106,239,239,248,96,209,76,54,102,69,29,243, > > 102,2,116,4,123,146,48,168,222,10,118,15,239, > > 149,110,189,201,55,230,26,13,172,137,72,91, > > 204,131,54,194,245,70,92,89,130,86,180,213, > > 254,35,180,216,84,28,68,171,196,167,229,20, > > 206,60,65,97,124,67,230,205,196,129,9,139,36, > > 251,84,37,214,22,168,150,12,103,7,111,179,80, > > 71,227,28,36,40,221,42,152,164,97,254,219,234, > > 18,55,188,1,26,52,133,189,110,79,231,145,114, > > 7,68,133,30,88,202,84,68,221,247,172,185,203, > > 137,33,114,219,143,192,105,41,151,42,163,174, > > 24,35,151,28,65,42,139,124,42,193,124,144,232, > > 169,40,192,211,145,198,173,40,135,64,104,181, > > 255,236,167,210,211,56,24,156,211,125,105,93, > > 240,198,165,30,36,27,163,71,252,105,7,104,231, > > 228,154,180,237,15,161,135,135,2,206,135,210, > > 72,78,225,188,255,203,241,114,146,68,100,3,37, > > 234,222,91,110,159,201,242,78,172,221,199>> > Due to decoding error:{badmatch, > {error, > {asn1, > {{case_clause,19}, > [{'OTP-PUB-KEY', > check_and_convert_restricted_string,5}, > {'OTP-PUB-KEY',decode,2}, > {pubkey_cert_records,transform,2}, > {lists,map,2}, > {lists,map,2}, > {pubkey_cert_records,transform,2}, > {pubkey_cert_records,decode_tbs,1}, > {pubkey_cert_records,decode_cert,1}]}}}} > > Reason: {bad_cert,missing_basic_constraint} > > =ERROR REPORT==== 22-Sep-2010::16:10:13 === > SSL: certify_certificate: ./ssl_handshake.erl:586:Fatal error: > handshake failure > ** exception error: no match of right hand side value {error,esslconnect} > in function ssl_test:test/0 > 3> > > Does this error rings a bell? > > cheers > > On Wed, Sep 22, 2010 at 2:11 PM, Ingela Anderton Andin > > wrote: > > Hi again, something went wrong with the branch please look at the > branch ia/ssl-and-public_key/backwards-compatibility/OTP-8858 > instead. > > > Regards Ingela Erlang/OTP team - Ericsson AB > > Ingela Anderton Andin wrote: > > Hi again! > > Well ok, first I would like you to provide the option verify_fun: > > FunAndState = {fun(_,{bad_cert, _} = Reason, _) -> > io:format("Reason: ~p~n", [Reason]), > {fail, Reason}; > (_,{extension, _}, UserState) -> > {unknown, UserState}; > (_, valid, UserState) -> > {valid, UserState} > end, []}, > > add option: > {verify_fun, FunAndState} > > So we can try to find out why it does not like the cert. > > By the way we decided to shorten the INFO report if you would > like to run the latest ssl it is now > on the branch ia/ssl/public_key/backwards-compatibility/OTP-8858. > > > > > > Regards Ingela Erlang/OTP team - Ericsson AB > > Filipe David Manana wrote: > > On Tue, Sep 21, 2010 at 4:07 PM, Ingela Anderton Andin > > >> wrote: > > Hi! > > Yes you could, it is a INFO report a warning that that > particular > CA cert is ignored as we could not decode it. > But you get another handshake error. What options do > you connect > with ? > > > This is an excerpt of my testing code: > > Options = [ > {ssl_imp, new}, > binary, > {nodelay, true}, > {active, false}, > {verify, verify_peer}, > {depth, 3}, > {cacertfile, > "/etc/ssl/certs/ca-certificates.crt"} > ], > {ok, S} = ssl:connect(?HOST, 443, Options), > ok = ssl:send(S, Body), > loop(S), > ssl:close(S). > > loop(S) -> > ssl:setopts(S, [{active, once}]), > receive > {ssl, S, Data} -> > io:format("received data: ~p~n", [Data]), > loop(S); > {ssl_closed, S} -> > io:format("socket closed", []); > {ssl_error, S, Error} -> > io:format("socket error: ~p~n", [Error]) > end. > > Once again, thanks for looking into this. > > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > Filipe David Manana wrote: > > Ingela, > > After pulling your last commit, things advance a > bit more, but > still not able to open the CAs file: > > =INFO REPORT==== 21-Sep-2010::14:35:58 === > SSL WARNING: Ignoring CA cert: > <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, > > 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, > > 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, > > 156,82,75,84,82,85,83,84,32,69,108,101,107, > > 116,114,111,110,105,107,32,83,101,114,116,105, > > 102,105,107,97,32,72,105,122,109,101,116,32, > > 83,97,196,159,108,97,121,196,177,99,196,177, > > 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, > > 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, > > 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, > > 48,48,53,32,84,195,156,82,75,84,82,85,83,84, > > 32,66,105,108,103,105,32,196,176,108,101,116, > > 105,197,159,105,109,32,118,101,32,66,105,108, > > 105,197,159,105,109,32,71,195,188,118,101,110, > > 108,105,196,159,105,32,72,105,122,109,101,116, > > 108,101,114,105,32,65,46,197,158,46,48,30,23, > > 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, > > 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, > > 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, > > 156,82,75,84,82,85,83,84,32,69,108,101,107, > > 116,114,111,110,105,107,32,83,101,114,116,105, > > 102,105,107,97,32,72,105,122,109,101,116,32, > > 83,97,196,159,108,97,121,196,177,99,196,177, > > 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, > > 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, > > 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, > > 48,48,53,32,84,195,156,82,75,84,82,85,83,84, > > 32,66,105,108,103,105,32,196,176,108,101,116, > > 105,197,159,105,109,32,118,101,32,66,105,108, > > 105,197,159,105,109,32,71,195,188,118,101,110, > > 108,105,196,159,105,32,72,105,122,109,101,116, > > 108,101,114,105,32,65,46,197,158,46,48,130,1, > > 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, > > 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, > > 214,99,3,216,28,95,221,210,123,93,242,12,96, > > 97,91,107,59,116,43,120,13,125,69,189,34,116, > > 232,140,3,193,198,17,42,61,149,188,169,148, > > 176,187,145,151,200,105,124,132,197,180,145, > > 108,108,19,106,164,85,173,164,133,232,149,126, > > 179,0,175,0,194,5,24,245,112,157,54,139,174, > > 203,228,27,129,127,147,136,251,106,85,187,125, > > 133,146,206,186,88,159,219,50,197,189,93,239, > > 34,74,47,65,7,126,73,97,179,134,236,78,166,65, > > 110,132,188,3,236,245,59,28,200,31,194,238, > > 168,238,234,18,74,141,20,207,243,10,224,80,57, > > 249,8,53,248,17,89,173,231,34,234,75,202,20,6, > > 222,66,186,178,153,243,45,84,136,16,6,234,225, > > 26,62,61,103,31,251,206,251,124,130,232,17,93, > > 74,193,185,20,234,84,217,102,155,124,137,125, > > 4,154,98,201,233,82,60,158,156,239,210,245,38, > > 228,230,229,24,124,139,110,223,108,204,120,91, > > 79,114,178,203,92,63,140,5,141,209,76,140,173, > > 146,199,225,120,127,101,108,73,6,80,44,158,50, > > 194,215,74,198,117,138,89,78,117,111,71,94, > > 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, > > 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, > > 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, > > 128,89,33,164,252,161,21,76,32,246,212,95,218, > > 3,36,252,207,144,26,244,33,10,154,238,58,177, > > 106,239,239,248,96,209,76,54,102,69,29,243, > > 102,2,116,4,123,146,48,168,222,10,118,15,239, > > 149,110,189,201,55,230,26,13,172,137,72,91, > > 204,131,54,194,245,70,92,89,130,86,180,213, > > 254,35,180,216,84,28,68,171,196,167,229,20, > > 206,60,65,97,124,67,230,205,196,129,9,139,36, > > 251,84,37,214,22,168,150,12,103,7,111,179,80, > > 71,227,28,36,40,221,42,152,164,97,254,219,234, > > 18,55,188,1,26,52,133,189,110,79,231,145,114, > > 7,68,133,30,88,202,84,68,221,247,172,185,203, > > 137,33,114,219,143,192,105,41,151,42,163,174, > > 24,35,151,28,65,42,139,124,42,193,124,144,232, > > 169,40,192,211,145,198,173,40,135,64,104,181, > > 255,236,167,210,211,56,24,156,211,125,105,93, > > 240,198,165,30,36,27,163,71,252,105,7,104,231, > > 228,154,180,237,15,161,135,135,2,206,135,210, > > 72,78,225,188,255,203,241,114,146,68,100,3,37, > > 234,222,91,110,159,201,242,78,172,221,199>> > Due to decoding error:{badmatch, > {error, > {asn1, > {{case_clause,19}, > [{'OTP-PUB-KEY', > > check_and_convert_restricted_string,5}, > {'OTP-PUB-KEY',decode,2}, > > {pubkey_cert_records,transform,2}, > {lists,map,2}, > {lists,map,2}, > > {pubkey_cert_records,transform,2}, > > {pubkey_cert_records,decode_tbs,1}, > > {pubkey_cert_records,decode_cert,1}]}}}} > > > =ERROR REPORT==== 21-Sep-2010::14:35:58 === > SSL: certify_certificate: > ./ssl_handshake.erl:584:Fatal error: > handshake failure > ** exception error: no match of right hand side value > {error,esslconnect} > in function ssl_test:test/0 > > > cheers > > On Tue, Sep 21, 2010 at 1:07 PM, Ingela Anderton Andin > > > > > >>> wrote: > > Hi! > > Filipe David Manana wrote: > > On Mon, Sep 20, 2010 at 2:47 PM, Ingela > Anderton Andin < > ingela@REDACTED > > > > > >>> wrote: > > So I definitely consider > this a regression :( > The weird thing is that I can use > this certificates > file with the old ssl > implementation (default on R13 and R12 > releases) on > R13B03 > and R13B04 at > least. > Well the thing is that the old > ssl-implementation > only is > an erlang-glue > that leaves the most things up to the > underlaying > openssl > implementation, > but the new ssl > only uses openssl crypto library and > takes care the ssl > protocol > fsm-machinery and certificate handling > on its > own. This > makes many things > much easier to implement > and removes the bottleneck enforced by > the glue, > and also > lessens the > required resource allocation. Of course > this may > cause new > bugs occasionally > and we fix them > as fast as we can. > If you want to try out the latest > changes to fix the > DSS-Params bug you can > get the branch > ia/ssl-asn1-spec-dss-params at my github > account > git@REDACTED:IngelaAndin/otp.git > > Hi, > > Ingela, I tried your git branch > ssl-asn1-spec-dss-params but > unfortunatelly > I still get an exception: > > =ERROR REPORT==== 21-Sep-2010::11:57:03 === > SSL: 1060: error:{error, > {asn1, > {{case_clause,19}, > [{'OTP-PUB-KEY', > > check_and_convert_restricted_string,5}, > > {'OTP-PUB-KEY',decode,2}, > > {pubkey_cert_records,transform,2}, > {lists,map,2}, > {lists,map,2}, > > {pubkey_cert_records,transform,2}, > > {pubkey_cert_records,decode_tbs,1}, > > {pubkey_cert_records,decode_cert,2}]}}} > > /home/fdmanana/tmp/ibrowse-test/ca-certificates.crt > [] > > ** exception error: no match of right hand > side value > {error,ecacertfile} > > > Yes I get this too, it seems to be > that one of the > certificates in > the file > has a field that is utf8-encoded but the > asn-1-spec says > that it > should > be a "printableString". I do not know if > openssl tries to > decode > it, it might > not until it is used, and it might not be. > Erlang ssl > caches all > cert in the ca-file. > I have now made new ssl more tolerant so that it > will ignore such ca-certs, that does not follow > the spec. > I have > pushed the change to > the ia/ssl-asn1-spec-dss-params branch. > > > And btw, with the old ssl implementation, > using a ssl > socket > in {active, > once} mode, I receive very often an error > like this: > > [Thu, 16 Sep 2010 00:10:34 GMT] [error] > [<0.604.0>] ** > Generic > server > <0.604.0> terminating > ** Last message in was {tcp,#Port<0.2288>, > > > <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>} > > ** When Server state == > > {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false, > [{mode,binary}, > {nodelay,true}, > {active,once}, > {packet,0}, > {ip,{0,0,0,0}}, > {verify,0}, > {depth,1}], > > {sslsocket,11,<0.604.0>}, > > #Port<0.2288>,nil,open,false,false} > > > The data, third argument of the tuple, is > what is > supposed to > be. However > the ssl module trows that exception (since > it was > expecting to > receive only > messages like {ssl, Socket, Data}). Is this > a known issue? > > > Humm ... not that I know of. We > are aiming to remove the old > ssl-implementation as soon as the new one is > compleate > enough and > in first hand we do not fix things in the old > implementation. > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org > > mailing list. > > See http://www.erlang.org/faq.html > To unsubscribe; > mailto:erlang-bugs-unsubscribe@REDACTED > > > > > >> > > > > > -- Filipe David Manana, > fdmanana@REDACTED > > > >>, > fdmanana@REDACTED > > > >> > > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org > mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; > mailto:erlang-bugs-unsubscribe@REDACTED > > > > > > > > -- > Filipe David Manana, > fdmanana@REDACTED > >, > fdmanana@REDACTED > > > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > > > > > > > > -- > Filipe David Manana, > fdmanana@REDACTED , fdmanana@REDACTED > > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > From fdmanana@REDACTED Thu Sep 23 13:28:41 2010 From: fdmanana@REDACTED (Filipe David Manana) Date: Thu, 23 Sep 2010 12:28:41 +0100 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: <4C9B1B88.4020609@erix.ericsson.se> References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> <4C989FFC.9060806@erix.ericsson.se> <4C98CA31.4010301@erix.ericsson.se> <4C99B4D7.5020307@erix.ericsson.se> <4C9A009A.4060803@erix.ericsson.se> <4C9B1B88.4020609@erix.ericsson.se> Message-ID: Ingela, I applied that patch and it's working now :) It does still print the warning =INFO REPORT==== 23-Sep-2010::12:24:43 === SSL WARNING: Ignoring CA cert: <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, 156,82,75,84,82,85,83,84,32,69,108,101,107, 116,114,111,110,105,107,32,83,101,114,116,105, 102,105,107,97,32,72,105,122,109,101,116,32, 83,97,196,159,108,97,121,196,177,99,196,177, 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, 48,48,53,32,84,195,156,82,75,84,82,85,83,84, 32,66,105,108,103,105,32,196,176,108,101,116, 105,197,159,105,109,32,118,101,32,66,105,108, 105,197,159,105,109,32,71,195,188,118,101,110, 108,105,196,159,105,32,72,105,122,109,101,116, 108,101,114,105,32,65,46,197,158,46,48,30,23, 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, 156,82,75,84,82,85,83,84,32,69,108,101,107, 116,114,111,110,105,107,32,83,101,114,116,105, 102,105,107,97,32,72,105,122,109,101,116,32, 83,97,196,159,108,97,121,196,177,99,196,177, 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, 48,48,53,32,84,195,156,82,75,84,82,85,83,84, 32,66,105,108,103,105,32,196,176,108,101,116, 105,197,159,105,109,32,118,101,32,66,105,108, 105,197,159,105,109,32,71,195,188,118,101,110, 108,105,196,159,105,32,72,105,122,109,101,116, 108,101,114,105,32,65,46,197,158,46,48,130,1, 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, 214,99,3,216,28,95,221,210,123,93,242,12,96, 97,91,107,59,116,43,120,13,125,69,189,34,116, 232,140,3,193,198,17,42,61,149,188,169,148, 176,187,145,151,200,105,124,132,197,180,145, 108,108,19,106,164,85,173,164,133,232,149,126, 179,0,175,0,194,5,24,245,112,157,54,139,174, 203,228,27,129,127,147,136,251,106,85,187,125, 133,146,206,186,88,159,219,50,197,189,93,239, 34,74,47,65,7,126,73,97,179,134,236,78,166,65, 110,132,188,3,236,245,59,28,200,31,194,238, 168,238,234,18,74,141,20,207,243,10,224,80,57, 249,8,53,248,17,89,173,231,34,234,75,202,20,6, 222,66,186,178,153,243,45,84,136,16,6,234,225, 26,62,61,103,31,251,206,251,124,130,232,17,93, 74,193,185,20,234,84,217,102,155,124,137,125, 4,154,98,201,233,82,60,158,156,239,210,245,38, 228,230,229,24,124,139,110,223,108,204,120,91, 79,114,178,203,92,63,140,5,141,209,76,140,173, 146,199,225,120,127,101,108,73,6,80,44,158,50, 194,215,74,198,117,138,89,78,117,111,71,94, 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, 128,89,33,164,252,161,21,76,32,246,212,95,218, 3,36,252,207,144,26,244,33,10,154,238,58,177, 106,239,239,248,96,209,76,54,102,69,29,243, 102,2,116,4,123,146,48,168,222,10,118,15,239, 149,110,189,201,55,230,26,13,172,137,72,91, 204,131,54,194,245,70,92,89,130,86,180,213, 254,35,180,216,84,28,68,171,196,167,229,20, 206,60,65,97,124,67,230,205,196,129,9,139,36, 251,84,37,214,22,168,150,12,103,7,111,179,80, 71,227,28,36,40,221,42,152,164,97,254,219,234, 18,55,188,1,26,52,133,189,110,79,231,145,114, 7,68,133,30,88,202,84,68,221,247,172,185,203, 137,33,114,219,143,192,105,41,151,42,163,174, 24,35,151,28,65,42,139,124,42,193,124,144,232, 169,40,192,211,145,198,173,40,135,64,104,181, 255,236,167,210,211,56,24,156,211,125,105,93, 240,198,165,30,36,27,163,71,252,105,7,104,231, 228,154,180,237,15,161,135,135,2,206,135,210, 72,78,225,188,255,203,241,114,146,68,100,3,37, 234,222,91,110,159,201,242,78,172,221,199>> Due to decoding error:{badmatch, {error, {asn1, {{case_clause,19}, [{'OTP-PUB-KEY', check_and_convert_restricted_string,5}, {'OTP-PUB-KEY',decode,2}, {pubkey_cert_records,transform,2}, {lists,map,2}, {lists,map,2}, {pubkey_cert_records,transform,2}, {pubkey_cert_records,decode_tbs,1}, {pubkey_cert_records,decode_cert,1}]}}}} 14 (as it's supposed to) I noticed you deleted your github branch. I'm interested in patching OTP R13B03 / R13B04 and eventually R14. Which commits from your now deleted github branch (still have a local copy) do I need to pick? thanks for all the good work on this best regards, On Thu, Sep 23, 2010 at 10:19 AM, Ingela Anderton Andin wrote: > Hi! > > Possible if your certificate is an old one the extension validation > could come up with the result missing_basic_constraint when it should > not, and in that case the following patch should help. > > diff --git a/lib/public_key/src/pubkey_cert.erl > b/lib/public_key/src/pubkey_cert.erl > index 2335a4e..85d4e29 100644 > --- a/lib/public_key/src/pubkey_cert.erl > +++ b/lib/public_key/src/pubkey_cert.erl > @@ -223,10 +223,15 @@ validate_revoked_status(_OtpCert, UserState, > _VerifyFun) -> > %%-------------------------------------------------------------------- > validate_extensions(OtpCert, ValidationState, UserState, VerifyFun) -> > ? ?TBSCert = OtpCert#'OTPCertificate'.tbsCertificate, > - ? ?Extensions = TBSCert#'OTPTBSCertificate'.extensions, > - ? ?validate_extensions(OtpCert, Extensions, ValidationState, > no_basic_constraint, > - ? ? ? ? ? ? ? ? ? ? ? is_self_signed(OtpCert), UserState, VerifyFun). > - > + ? ?case TBSCert#'OTPTBSCertificate'.version of > + ? ? ? N when N >= 3 -> > + ? ? ? ? ? Extensions = TBSCert#'OTPTBSCertificate'.extensions, > + ? ? ? ? ? validate_extensions(OtpCert, Extensions, > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ValidationState, no_basic_constraint, > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? is_self_signed(OtpCert), UserState, > VerifyFun); > + ? ? ? _ -> %% Extensions not present in versions 1 & 2 > + ? ? ? ? ? {ValidationState, UserState} > + ? ?end. > %%-------------------------------------------------------------------- > -spec normalize_general_name({rdnSequence, term()}) -> {rdnSequence, > term()}. > %% > > > Can this be the problem? > > Regards ?Ingela Erlang/OTP Team - Ericsson AB > > Filipe David Manana wrote: >> >> Ingela, some progress with that branch: >> >> 2> ssl_test:test(). >> >> =INFO REPORT==== 22-Sep-2010::16:10:13 === >> SSL WARNING: Ignoring CA cert: >> <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, >> >> 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, >> >> 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, >> >> 156,82,75,84,82,85,83,84,32,69,108,101,107, >> >> 116,114,111,110,105,107,32,83,101,114,116,105, >> >> 102,105,107,97,32,72,105,122,109,101,116,32, >> >> 83,97,196,159,108,97,121,196,177,99,196,177, >> >> 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, >> >> 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, >> >> 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, >> >> 48,48,53,32,84,195,156,82,75,84,82,85,83,84, >> >> 32,66,105,108,103,105,32,196,176,108,101,116, >> >> 105,197,159,105,109,32,118,101,32,66,105,108, >> >> 105,197,159,105,109,32,71,195,188,118,101,110, >> >> 108,105,196,159,105,32,72,105,122,109,101,116, >> >> 108,101,114,105,32,65,46,197,158,46,48,30,23, >> >> 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, >> >> 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, >> >> 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, >> >> 156,82,75,84,82,85,83,84,32,69,108,101,107, >> >> 116,114,111,110,105,107,32,83,101,114,116,105, >> >> 102,105,107,97,32,72,105,122,109,101,116,32, >> >> 83,97,196,159,108,97,121,196,177,99,196,177, >> >> 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, >> >> 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, >> >> 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, >> >> 48,48,53,32,84,195,156,82,75,84,82,85,83,84, >> >> 32,66,105,108,103,105,32,196,176,108,101,116, >> >> 105,197,159,105,109,32,118,101,32,66,105,108, >> >> 105,197,159,105,109,32,71,195,188,118,101,110, >> >> 108,105,196,159,105,32,72,105,122,109,101,116, >> >> 108,101,114,105,32,65,46,197,158,46,48,130,1, >> >> 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, >> >> 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, >> >> 214,99,3,216,28,95,221,210,123,93,242,12,96, >> >> 97,91,107,59,116,43,120,13,125,69,189,34,116, >> >> 232,140,3,193,198,17,42,61,149,188,169,148, >> >> 176,187,145,151,200,105,124,132,197,180,145, >> >> 108,108,19,106,164,85,173,164,133,232,149,126, >> >> 179,0,175,0,194,5,24,245,112,157,54,139,174, >> >> 203,228,27,129,127,147,136,251,106,85,187,125, >> >> 133,146,206,186,88,159,219,50,197,189,93,239, >> >> 34,74,47,65,7,126,73,97,179,134,236,78,166,65, >> >> 110,132,188,3,236,245,59,28,200,31,194,238, >> >> 168,238,234,18,74,141,20,207,243,10,224,80,57, >> >> 249,8,53,248,17,89,173,231,34,234,75,202,20,6, >> >> 222,66,186,178,153,243,45,84,136,16,6,234,225, >> >> 26,62,61,103,31,251,206,251,124,130,232,17,93, >> >> 74,193,185,20,234,84,217,102,155,124,137,125, >> >> 4,154,98,201,233,82,60,158,156,239,210,245,38, >> >> 228,230,229,24,124,139,110,223,108,204,120,91, >> >> 79,114,178,203,92,63,140,5,141,209,76,140,173, >> >> 146,199,225,120,127,101,108,73,6,80,44,158,50, >> >> 194,215,74,198,117,138,89,78,117,111,71,94, >> >> 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, >> >> 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, >> >> 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, >> >> 128,89,33,164,252,161,21,76,32,246,212,95,218, >> >> 3,36,252,207,144,26,244,33,10,154,238,58,177, >> >> 106,239,239,248,96,209,76,54,102,69,29,243, >> >> 102,2,116,4,123,146,48,168,222,10,118,15,239, >> >> 149,110,189,201,55,230,26,13,172,137,72,91, >> >> 204,131,54,194,245,70,92,89,130,86,180,213, >> >> 254,35,180,216,84,28,68,171,196,167,229,20, >> >> 206,60,65,97,124,67,230,205,196,129,9,139,36, >> >> 251,84,37,214,22,168,150,12,103,7,111,179,80, >> >> 71,227,28,36,40,221,42,152,164,97,254,219,234, >> >> 18,55,188,1,26,52,133,189,110,79,231,145,114, >> >> 7,68,133,30,88,202,84,68,221,247,172,185,203, >> >> 137,33,114,219,143,192,105,41,151,42,163,174, >> >> 24,35,151,28,65,42,139,124,42,193,124,144,232, >> >> 169,40,192,211,145,198,173,40,135,64,104,181, >> >> 255,236,167,210,211,56,24,156,211,125,105,93, >> >> 240,198,165,30,36,27,163,71,252,105,7,104,231, >> >> 228,154,180,237,15,161,135,135,2,206,135,210, >> >> 72,78,225,188,255,203,241,114,146,68,100,3,37, >> >> 234,222,91,110,159,201,242,78,172,221,199>> >> ?Due to decoding error:{badmatch, >> ? ? ? ? ? ? ? ? ? ? ? ?{error, >> ? ? ? ? ? ? ? ? ? ? ? ? {asn1, >> ? ? ? ? ? ? ? ? ? ? ? ? ?{{case_clause,19}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? [{'OTP-PUB-KEY', >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? check_and_convert_restricted_string,5}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?{'OTP-PUB-KEY',decode,2}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?{pubkey_cert_records,transform,2}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?{lists,map,2}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?{lists,map,2}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?{pubkey_cert_records,transform,2}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?{pubkey_cert_records,decode_tbs,1}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?{pubkey_cert_records,decode_cert,1}]}}}} >> >> Reason: {bad_cert,missing_basic_constraint} >> >> =ERROR REPORT==== 22-Sep-2010::16:10:13 === >> SSL: certify_certificate: ./ssl_handshake.erl:586:Fatal error: handshake >> failure >> ** exception error: no match of right hand side value {error,esslconnect} >> ? ? in function ?ssl_test:test/0 >> 3> >> >> Does this error rings a bell? >> >> cheers >> >> On Wed, Sep 22, 2010 at 2:11 PM, Ingela Anderton Andin >> > wrote: >> >> ? ?Hi again, something went wrong with the branch please look at the >> ? ?branch ia/ssl-and-public_key/backwards-compatibility/OTP-8858 >> ? ? instead. >> >> >> ? ?Regards Ingela Erlang/OTP team - Ericsson AB >> >> ? ?Ingela Anderton Andin wrote: >> >> ? ? ? ?Hi again! >> >> ? ? ? ?Well ok, first I would like you to provide the option verify_fun: >> >> ? ? ? ? FunAndState = ?{fun(_,{bad_cert, _} = Reason, _) -> >> ? ? ? ? ? ? ? ? io:format("Reason: ~p~n", [Reason]), >> ? ? ? ? ? ? ? {fail, Reason}; >> ? ? ? ? ? ? ?(_,{extension, _}, UserState) -> >> ? ? ? ? ? ? ? {unknown, UserState}; >> ? ? ? ? ? ? ?(_, valid, UserState) -> >> ? ? ? ? ? ? ? {valid, UserState} >> ? ? ? ? ? end, []}, >> >> ? ? ? ?add option: >> ? ? ? ?{verify_fun, FunAndState} >> >> ? ? ? ?So we can try to find out why it does not like the cert. >> >> ? ? ? ?By the way we decided to shorten the INFO report if you would >> ? ? ? ?like to run the latest ssl it is now >> ? ? ? ?on the branch ia/ssl/public_key/backwards-compatibility/OTP-8858. >> >> >> >> >> >> ? ? ? ?Regards Ingela Erlang/OTP team - Ericsson AB >> >> ? ? ? ?Filipe David Manana wrote: >> >> ? ? ? ? ? ?On Tue, Sep 21, 2010 at 4:07 PM, Ingela Anderton Andin >> ? ? ? ? ? ? >> ? ? ? ? ? ?> ? ? ? ? ? ?>> wrote: >> >> ? ? ? ? ? ? ? Hi! >> >> ? ? ? ? ? ? ? Yes you could, it is a INFO report a warning that that >> ? ? ? ? ? ?particular >> ? ? ? ? ? ? ? CA cert is ignored as we could not decode it. >> ? ? ? ? ? ? ? But you get another handshake error. ?What options do >> ? ? ? ? ? ?you connect >> ? ? ? ? ? ? ? with ? >> >> >> ? ? ? ? ? ?This is an excerpt of my testing code: >> >> ? ? ? ? ? ? ? ? ? ? Options = [ >> ? ? ? ? ? ? ? ? ? ? ? ? ? {ssl_imp, new}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? binary, >> ? ? ? ? ? ? ? ? ? ? ? ? ? {nodelay, true}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? {active, false}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? {verify, verify_peer}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? {depth, 3}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? {cacertfile, >> ? ? ? ? ? ?"/etc/ssl/certs/ca-certificates.crt"} >> ? ? ? ? ? ? ? ], >> ? ? ? ? ? ? ? {ok, S} = ssl:connect(?HOST, 443, Options), >> ? ? ? ? ? ? ? ok = ssl:send(S, Body), >> ? ? ? ? ? ? ? loop(S), >> ? ? ? ? ? ? ? ssl:close(S). >> >> ? ? ? ? ? ?loop(S) -> >> ? ? ? ? ? ? ? ssl:setopts(S, [{active, once}]), >> ? ? ? ? ? ? ? receive >> ? ? ? ? ? ? ? {ssl, S, Data} -> >> ? ? ? ? ? ? ? ? ? io:format("received data: ?~p~n", [Data]), >> ? ? ? ? ? ? ? ? ? loop(S); >> ? ? ? ? ? ? ? {ssl_closed, S} -> >> ? ? ? ? ? ? ? ? ? io:format("socket closed", []); >> ? ? ? ? ? ? ? {ssl_error, S, Error} -> >> ? ? ? ? ? ? ? ? ? io:format("socket error: ?~p~n", [Error]) >> ? ? ? ? ? ? ? end. >> ? ? ? ? ? ? ? ? ? ? ? ? Once again, thanks for looking into this. >> >> >> >> ? ? ? ? ? ? ? Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> ? ? ? ? ? ? ? Filipe David Manana wrote: >> >> ? ? ? ? ? ? ? ? ? Ingela, >> >> ? ? ? ? ? ? ? ? ? After pulling your last commit, things advance a >> ? ? ? ? ? ?bit more, but >> ? ? ? ? ? ? ? ? ? still not able to open the CAs file: >> >> ? ? ? ? ? ? ? ? ? =INFO REPORT==== 21-Sep-2010::14:35:58 === >> ? ? ? ? ? ? ? ? ? SSL WARNING: Ignoring CA cert: >> ? ? ? ? ? ? ? ? ? <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, >> >> 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, >> >> 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, >> >> 156,82,75,84,82,85,83,84,32,69,108,101,107, >> >> 116,114,111,110,105,107,32,83,101,114,116,105, >> >> 102,105,107,97,32,72,105,122,109,101,116,32, >> >> 83,97,196,159,108,97,121,196,177,99,196,177, >> >> 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, >> >> 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, >> >> 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, >> >> 48,48,53,32,84,195,156,82,75,84,82,85,83,84, >> >> 32,66,105,108,103,105,32,196,176,108,101,116, >> >> 105,197,159,105,109,32,118,101,32,66,105,108, >> >> 105,197,159,105,109,32,71,195,188,118,101,110, >> >> 108,105,196,159,105,32,72,105,122,109,101,116, >> >> 108,101,114,105,32,65,46,197,158,46,48,30,23, >> >> 13,48,53,48,53,49,51,49,48,50,55,49,55,90,23, >> >> 13,49,53,48,51,50,50,49,48,50,55,49,55,90,48, >> >> 129,183,49,63,48,61,6,3,85,4,3,12,54,84,195, >> >> 156,82,75,84,82,85,83,84,32,69,108,101,107, >> >> 116,114,111,110,105,107,32,83,101,114,116,105, >> >> 102,105,107,97,32,72,105,122,109,101,116,32, >> >> 83,97,196,159,108,97,121,196,177,99,196,177, >> >> 115,196,177,49,11,48,9,6,3,85,4,6,12,2,84,82, >> >> 49,15,48,13,6,3,85,4,7,12,6,65,78,75,65,82,65, >> >> 49,86,48,84,6,3,85,4,10,12,77,40,99,41,32,50, >> >> 48,48,53,32,84,195,156,82,75,84,82,85,83,84, >> >> 32,66,105,108,103,105,32,196,176,108,101,116, >> >> 105,197,159,105,109,32,118,101,32,66,105,108, >> >> 105,197,159,105,109,32,71,195,188,118,101,110, >> >> 108,105,196,159,105,32,72,105,122,109,101,116, >> >> 108,101,114,105,32,65,46,197,158,46,48,130,1, >> >> 34,48,13,6,9,42,134,72,134,247,13,1,1,1,5,0,3, >> >> 130,1,15,0,48,130,1,10,2,130,1,1,0,202,82,5, >> >> 214,99,3,216,28,95,221,210,123,93,242,12,96, >> >> 97,91,107,59,116,43,120,13,125,69,189,34,116, >> >> 232,140,3,193,198,17,42,61,149,188,169,148, >> >> 176,187,145,151,200,105,124,132,197,180,145, >> >> 108,108,19,106,164,85,173,164,133,232,149,126, >> >> 179,0,175,0,194,5,24,245,112,157,54,139,174, >> >> 203,228,27,129,127,147,136,251,106,85,187,125, >> >> 133,146,206,186,88,159,219,50,197,189,93,239, >> >> 34,74,47,65,7,126,73,97,179,134,236,78,166,65, >> >> 110,132,188,3,236,245,59,28,200,31,194,238, >> >> 168,238,234,18,74,141,20,207,243,10,224,80,57, >> >> 249,8,53,248,17,89,173,231,34,234,75,202,20,6, >> >> 222,66,186,178,153,243,45,84,136,16,6,234,225, >> >> 26,62,61,103,31,251,206,251,124,130,232,17,93, >> >> 74,193,185,20,234,84,217,102,155,124,137,125, >> >> 4,154,98,201,233,82,60,158,156,239,210,245,38, >> >> 228,230,229,24,124,139,110,223,108,204,120,91, >> >> 79,114,178,203,92,63,140,5,141,209,76,140,173, >> >> 146,199,225,120,127,101,108,73,6,80,44,158,50, >> >> 194,215,74,198,117,138,89,78,117,111,71,94, >> >> 193,2,3,1,0,1,163,16,48,14,48,12,6,3,85,29,19, >> >> 4,5,48,3,1,1,255,48,13,6,9,42,134,72,134,247, >> >> 13,1,1,5,5,0,3,130,1,1,0,21,245,85,255,55,150, >> >> 128,89,33,164,252,161,21,76,32,246,212,95,218, >> >> 3,36,252,207,144,26,244,33,10,154,238,58,177, >> >> 106,239,239,248,96,209,76,54,102,69,29,243, >> >> 102,2,116,4,123,146,48,168,222,10,118,15,239, >> >> 149,110,189,201,55,230,26,13,172,137,72,91, >> >> 204,131,54,194,245,70,92,89,130,86,180,213, >> >> 254,35,180,216,84,28,68,171,196,167,229,20, >> >> 206,60,65,97,124,67,230,205,196,129,9,139,36, >> >> 251,84,37,214,22,168,150,12,103,7,111,179,80, >> >> 71,227,28,36,40,221,42,152,164,97,254,219,234, >> >> 18,55,188,1,26,52,133,189,110,79,231,145,114, >> >> 7,68,133,30,88,202,84,68,221,247,172,185,203, >> >> 137,33,114,219,143,192,105,41,151,42,163,174, >> >> 24,35,151,28,65,42,139,124,42,193,124,144,232, >> >> 169,40,192,211,145,198,173,40,135,64,104,181, >> >> 255,236,167,210,211,56,24,156,211,125,105,93, >> >> 240,198,165,30,36,27,163,71,252,105,7,104,231, >> >> 228,154,180,237,15,161,135,135,2,206,135,210, >> >> 72,78,225,188,255,203,241,114,146,68,100,3,37, >> >> 234,222,91,110,159,201,242,78,172,221,199>> >> ? ? ? ? ? ? ? ? ? ?Due to decoding error:{badmatch, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{error, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {asn1, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{{case_clause,19}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{'OTP-PUB-KEY', >> >> check_and_convert_restricted_string,5}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{'OTP-PUB-KEY',decode,2}, >> >> {pubkey_cert_records,transform,2}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{lists,map,2}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{lists,map,2}, >> >> {pubkey_cert_records,transform,2}, >> >> {pubkey_cert_records,decode_tbs,1}, >> >> ?{pubkey_cert_records,decode_cert,1}]}}}} >> >> >> ? ? ? ? ? ? ? ? ? =ERROR REPORT==== 21-Sep-2010::14:35:58 === >> ? ? ? ? ? ? ? ? ? SSL: certify_certificate: >> ? ? ? ? ? ?./ssl_handshake.erl:584:Fatal error: >> ? ? ? ? ? ? ? ? ? handshake failure >> ? ? ? ? ? ? ? ? ? ** exception error: no match of right hand side value >> ? ? ? ? ? ? ? ? ? {error,esslconnect} >> ? ? ? ? ? ? ? ? ? ? ? in function ?ssl_test:test/0 >> >> >> ? ? ? ? ? ? ? ? ? cheers >> >> ? ? ? ? ? ? ? ? ? On Tue, Sep 21, 2010 at 1:07 PM, Ingela Anderton Andin >> ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? >> ? ? ? ? ? ?> ? ? ? ? ? ?> >> ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? >> ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ?>>> wrote: >> >> ? ? ? ? ? ? ? ? ? ? ?Hi! >> >> ? ? ? ? ? ? ? ? ? ? ?Filipe David Manana wrote: >> >> ? ? ? ? ? ? ? ? ? ? ? ? ?On Mon, Sep 20, 2010 at 2:47 PM, Ingela >> ? ? ? ? ? ?Anderton Andin < >> ? ? ? ? ? ? ? ? ? ? ? ? ?ingela@REDACTED >> ? ? ? ? ? ? >> ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ?> >> ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? >> ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ?>>> wrote: >> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? So I definitely consider >> ? ? ? ? ? ?this a regression :( >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? The weird thing is that I can use >> ? ? ? ? ? ?this certificates >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?file with the old ssl >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?implementation (default on R13 and R12 >> ? ? ? ? ? ?releases) on >> ? ? ? ? ? ? ? ? ? R13B03 >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and R13B04 at >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?least. >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Well the thing is that the old >> ? ? ? ? ? ?ssl-implementation >> ? ? ? ? ? ? ? ? ? only is >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?an erlang-glue >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?that leaves the most things up to the >> ? ? ? ? ? ?underlaying >> ? ? ? ? ? ? ? ? ? openssl >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?implementation, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?but the new ssl >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?only uses openssl crypto library and >> ? ? ? ? ? ?takes care the ssl >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?protocol >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fsm-machinery and ?certificate ?handling >> ? ? ? ? ? ?on its >> ? ? ? ? ? ? ? ? ? own. This >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?makes many things >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?much easier to implement >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and removes the bottleneck enforced by >> ? ? ? ? ? ?the glue, >> ? ? ? ? ? ? ? ? ? and also >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?lessens the >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?required resource allocation. Of course >> ? ? ? ? ? ?this may >> ? ? ? ? ? ? ? ? ? cause new >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bugs occasionally >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and we fix them >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?as fast as we can. >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?If you want to try out the latest >> ? ? ? ? ? ?changes to fix the >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DSS-Params bug you can >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?get the branch >> ? ? ? ? ? ?ia/ssl-asn1-spec-dss-params at my github >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?account >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?git@REDACTED:IngelaAndin/otp.git >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Hi, >> >> ? ? ? ? ? ? ? ? ? ? ? ? ?Ingela, I tried your git branch >> ? ? ? ? ? ? ? ? ? ?ssl-asn1-spec-dss-params but >> ? ? ? ? ? ? ? ? ? ? ? ? ?unfortunatelly >> ? ? ? ? ? ? ? ? ? ? ? ? ?I still get an exception: >> >> ? ? ? ? ? ? ? ? ? ? ? ? ?=ERROR REPORT==== 21-Sep-2010::11:57:03 === >> ? ? ? ? ? ? ? ? ? ? ? ? ?SSL: 1060: error:{error, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{asn1, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{{case_clause,19}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{'OTP-PUB-KEY', >> >> ? ? ? check_and_convert_restricted_string,5}, >> >> {'OTP-PUB-KEY',decode,2}, >> >> ?{pubkey_cert_records,transform,2}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{lists,map,2}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{lists,map,2}, >> >> ?{pubkey_cert_records,transform,2}, >> >> ?{pubkey_cert_records,decode_tbs,1}, >> >> ?{pubkey_cert_records,decode_cert,2}]}}} >> >> /home/fdmanana/tmp/ibrowse-test/ca-certificates.crt >> ? ? ? ? ? ? ? ? ? ? ? ? ? [] >> >> ? ? ? ? ? ? ? ? ? ? ? ? ?** exception error: no match of right hand >> ? ? ? ? ? ?side value >> ? ? ? ? ? ? ? ? ? ? ? ? ?{error,ecacertfile} >> >> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Yes I get this too, it seems to be >> ? ? ? ? ? ?that one of the >> ? ? ? ? ? ? ? ? ? certificates in >> ? ? ? ? ? ? ? ? ? ? ?the file >> ? ? ? ? ? ? ? ? ? ? ?has a field that is utf8-encoded but the >> ? ? ? ? ? ?asn-1-spec says >> ? ? ? ? ? ? ? ? ? that it >> ? ? ? ? ? ? ? ? ? ? ?should >> ? ? ? ? ? ? ? ? ? ? ?be a "printableString". ?I do not know if >> ? ? ? ? ? ?openssl tries to >> ? ? ? ? ? ? ? ? ? decode >> ? ? ? ? ? ? ? ? ? ? ?it, it might >> ? ? ? ? ? ? ? ? ? ? ?not until it is used, and it might not be. >> ? ? ? ? ? ?Erlang ssl >> ? ? ? ? ? ? ? ? ? caches all >> ? ? ? ? ? ? ? ? ? ? ?cert in the ca-file. >> ? ? ? ? ? ? ? ? ? ? ?I have now made new ssl more tolerant so that it >> ? ? ? ? ? ? ? ? ? ? ?will ignore such ca-certs, that does not follow >> ? ? ? ? ? ?the spec. >> ? ? ? ? ? ? ? ? ? ?I have >> ? ? ? ? ? ? ? ? ? ? ?pushed the change to >> ? ? ? ? ? ? ? ? ? ? ?the ia/ssl-asn1-spec-dss-params branch. >> >> >> ? ? ? ? ? ? ? ? ? ? ? ? ?And btw, with the old ssl implementation, >> ? ? ? ? ? ?using a ssl >> ? ? ? ? ? ? ? ? ? socket >> ? ? ? ? ? ? ? ? ? ? ? ? ?in {active, >> ? ? ? ? ? ? ? ? ? ? ? ? ?once} mode, I receive very often an error >> ? ? ? ? ? ?like this: >> >> ? ? ? ? ? ? ? ? ? ? ? ? ?[Thu, 16 Sep 2010 00:10:34 GMT] [error] >> ? ? ? ? ? ?[<0.604.0>] ** >> ? ? ? ? ? ? ? ? ? Generic >> ? ? ? ? ? ? ? ? ? ? ? ? ?server >> ? ? ? ? ? ? ? ? ? ? ? ? ?<0.604.0> terminating >> ? ? ? ? ? ? ? ? ? ? ? ? ?** Last message in was {tcp,#Port<0.2288>, >> >> >> <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>} >> >> ? ? ? ? ? ? ? ? ? ? ? ? ?** When Server state == >> >> {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{mode,binary}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{nodelay,true}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {active,once}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{packet,0}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {ip,{0,0,0,0}}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{verify,0}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {depth,1}], >> >> ?{sslsocket,11,<0.604.0>}, >> >> ?#Port<0.2288>,nil,open,false,false} >> >> >> ? ? ? ? ? ? ? ? ? ? ? ? ?The data, third argument of the tuple, is >> ? ? ? ? ? ?what is >> ? ? ? ? ? ? ? ? ? supposed to >> ? ? ? ? ? ? ? ? ? ? ? ? ?be. However >> ? ? ? ? ? ? ? ? ? ? ? ? ?the ssl module trows that exception (since >> ? ? ? ? ? ?it was >> ? ? ? ? ? ? ? ? ? expecting to >> ? ? ? ? ? ? ? ? ? ? ? ? ?receive only >> ? ? ? ? ? ? ? ? ? ? ? ? ?messages like {ssl, Socket, Data}). Is this >> ? ? ? ? ? ?a known issue? >> >> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Humm ... not that I know of. ?We >> ? ? ? ? ? ?are aiming to remove the old >> ? ? ? ? ? ? ? ? ? ? ?ssl-implementation as soon as the new one is >> ? ? ? ? ? ?compleate >> ? ? ? ? ? ? ? ? ? enough and >> ? ? ? ? ? ? ? ? ? ? ?in first hand we do not fix things in the old >> ? ? ? ? ? ?implementation. >> >> >> ? ? ? ? ? ? ? ? ? ? ?Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> >> >> >> >> ?________________________________________________________________ >> ? ? ? ? ? ? ? ? ? ? ?erlang-bugs (at) erlang.org >> ? ? ? ? ? ? >> ? ? ? ? ? ? ? ? ? mailing list. >> >> ? ? ? ? ? ? ? ? ? ? ?See http://www.erlang.org/faq.html >> ? ? ? ? ? ? ? ? ? ? ?To unsubscribe; >> ? ? ? ? ? ?mailto:erlang-bugs-unsubscribe@REDACTED >> ? ? ? ? ? ? >> ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ?> >> ? ? ? ? ? ? ? ? ? ? ?> ? ? ? ? ? ? >> ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ?>> >> >> >> >> >> ? ? ? ? ? ? ? ? ? -- ? ? ? ? Filipe David Manana, >> ? ? ? ? ? ? ? ? ? fdmanana@REDACTED >> ? ? ? ? ? ?> >> ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? > ? ? ? ? ? ?>>, >> ? ? ? ? ? ? ? ? ? fdmanana@REDACTED >> ? ? ? ? ? ?> >> ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? > ? ? ? ? ? ?>> >> >> >> ? ? ? ? ? ? ? ? ? "Reasonable men adapt themselves to the world. >> ? ? ? ? ? ? ? ? ? ?Unreasonable men adapt the world to themselves. >> ? ? ? ? ? ? ? ? ? ?That's why all progress depends on unreasonable men." >> >> >> >> >> >> ?________________________________________________________________ >> ? ? ? ? ? ? ? erlang-bugs (at) erlang.org >> ? ? ? ? ? ? mailing list. >> ? ? ? ? ? ? ? See http://www.erlang.org/faq.html >> ? ? ? ? ? ? ? To unsubscribe; >> ? ? ? ? ? ?mailto:erlang-bugs-unsubscribe@REDACTED >> ? ? ? ? ? ? >> ? ? ? ? ? ? ? > ? ? ? ? ? ?> >> >> >> >> >> ? ? ? ? ? ?-- ? ? ? ? ? ? Filipe David Manana, >> ? ? ? ? ? ?fdmanana@REDACTED >> ? ? ? ? ? ?>, >> ? ? ? ? ? ?fdmanana@REDACTED >> ? ? ? ? ? ?> >> >> ? ? ? ? ? ?"Reasonable men adapt themselves to the world. >> ? ? ? ? ? ? Unreasonable men adapt the world to themselves. >> ? ? ? ? ? ? That's why all progress depends on unreasonable men." >> >> >> >> >> ? ? ? ?________________________________________________________________ >> ? ? ? ?erlang-bugs (at) erlang.org mailing list. >> ? ? ? ?See http://www.erlang.org/faq.html >> ? ? ? ?To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> ? ? ? ? >> >> >> >> >> >> >> >> -- >> Filipe David Manana, >> fdmanana@REDACTED , fdmanana@REDACTED >> >> >> "Reasonable men adapt themselves to the world. >> ?Unreasonable men adapt the world to themselves. >> ?That's why all progress depends on unreasonable men." >> > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. ?Unreasonable men adapt the world to themselves. ?That's why all progress depends on unreasonable men." From ingela@REDACTED Thu Sep 23 14:48:07 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Thu, 23 Sep 2010 14:48:07 +0200 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> <4C989FFC.9060806@erix.ericsson.se> <4C98CA31.4010301@erix.ericsson.se> <4C99B4D7.5020307@erix.ericsson.se> <4C9A009A.4060803@erix.ericsson.se> <4C9B1B88.4020609@erix.ericsson.se> Message-ID: <4C9B4C87.7090605@erix.ericsson.se> Hi! Filipe David Manana wrote: > Ingela, I applied that patch and it's working now :) > It does still print the warning > > =INFO REPORT==== 23-Sep-2010::12:24:43 === > SSL WARNING: Ignoring CA cert: <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, > [...] > > (as it's supposed to) > > I noticed you deleted your github branch. > I'm interested in patching OTP R13B03 / R13B04 and eventually R14. > Which commits from your now deleted github branch (still have a local > copy) do I need to pick? > You need the changes from the branch ia/ssl-asn1-spec-dss-params + the patch I sent you. If you want the shorter warning message you can pick it from the branch ia/ssl-and-public_key/backwards-compatibility/OTP-8858 that replaces the one I deleted that by mistake was almost identical to ia/ssl-asn1-spec-dss-params . Regards Ingela Erlang/OTP team - Ericsson AB From fdmanana@REDACTED Thu Sep 23 22:51:58 2010 From: fdmanana@REDACTED (Filipe David Manana) Date: Thu, 23 Sep 2010 21:51:58 +0100 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: <4C9B4C87.7090605@erix.ericsson.se> References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> <4C989FFC.9060806@erix.ericsson.se> <4C98CA31.4010301@erix.ericsson.se> <4C99B4D7.5020307@erix.ericsson.se> <4C9A009A.4060803@erix.ericsson.se> <4C9B1B88.4020609@erix.ericsson.se> <4C9B4C87.7090605@erix.ericsson.se> Message-ID: Regarding the suggestion: > 3) For the verify function, it receives {bad_cert, unknown_ca} when a certificate is self-signed? I would like to distinguish between unknown CAs and >self-signed certificates (certificate signed by the target host). >> I think you have a point here we will look in to this. Is there any standard (more formal) procedure to submit the suggestion to the OTP team, or posting to this mailing list is enough? cheers On Thu, Sep 23, 2010 at 1:48 PM, Ingela Anderton Andin wrote: > Hi! > > Filipe David Manana wrote: >> >> Ingela, I applied that patch and it's working now :) >> It does still print the warning >> >> =INFO REPORT==== 23-Sep-2010::12:24:43 === >> SSL WARNING: Ignoring CA cert: >> <<48,130,3,251,48,130,2,227,160,3,2,1,2,2,1,1, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [...] >> >> (as it's supposed to) >> ?I noticed you deleted your github branch. >> I'm interested in patching OTP R13B03 / R13B04 and eventually R14. >> Which commits from your now deleted github branch (still have a local >> copy) do I need to pick? >> > > You need the changes from the branch ia/ssl-asn1-spec-dss-params > + the > patch I sent you. > > If you want the shorter warning message you can pick it from the ?branch > > ia/ssl-and-public_key/backwards-compatibility/OTP-8858 > > > that replaces the one I deleted that by mistake was almost identical to > ia/ssl-asn1-spec-dss-params > . > > Regards Ingela Erlang/OTP team - Ericsson AB > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. ?Unreasonable men adapt the world to themselves. ?That's why all progress depends on unreasonable men." From john.hughes@REDACTED Thu Sep 23 23:22:48 2010 From: john.hughes@REDACTED (John Hughes) Date: Thu, 23 Sep 2010 23:22:48 +0200 Subject: Apparent race condition in dets can corrupt the file In-Reply-To: <1285241325.21526.ezmlm@erlang.org> References: <1285241325.21526.ezmlm@erlang.org> Message-ID: <48AC892C81794530989B2F81A7F87C97@JohnsTablet2009> It looks as though QuickCheck has turned up another race condition in dets, this one involving three processes. The minimal example is: ...ensure that the file dets_table does not exist... dets:open_file(dets_table,[{type,bag}]), dets:close(dets_table), dets:open_file(dets_table,[{type,bag}]), In parallel: dets:lookup(dets_table,0) dets:insert(dets_table,{0,0}) dets:insert(dets_table,{0,0}) dets:match_object(dets_table,'_') All calls return the correct results until the call to match_object, which returns {error,{premature_eof,"dets_table"}}. This looks as though it could be the same bug Tobbe T?rnqvist mentioned here: http://www.erlang.org/cgi-bin/ezmlm-cgi?4:msp:29771 "We know there is a lurking bug somewhere in the dets code. We have got 'bad object' and 'premature eof' every other month the last year. We have not been able to track the bug down since the dets files is repaired automatically next time it is opened." In this case too, the file is left in a state that causes it to be repaired when it is reopened. After the repair, though, the data inserted into the table has been lost. Caveats: * The race condition occurs only rarely--I need to repeat the test case up to hundreds of times to hit it. This repetition may perhaps be necessary to provoke the failure. * I'm using Windows... antivirus programs or even the file system itself might be involved. * I can only provoke the bug using QuickCheck--coding up the dets calls in a simple Erlang function does not seem to provoke it. I speculate that this is because QuickCheck makes the calls a little more slowly... it's interpreting the test case after all... so the timing is different, and that may affect the likelihood of hitting the race. Of course, QuickCheck is not calling dets internally. I'm attaching a copy of my test code, which tries the test up to 1000 times and, on my laptop, provokes the error virtually every time. You run it like this: Erlang R14B (erts-5.8.1) [smp:2:2] [rq:2] [async-threads:0] Eshell V5.8.1 (abort with ^G) 1> dets_eqc:bug(). Failed! Reason: {'EXIT',{badarg,[{erlang,length,[{error,{premature_eof,"dets_table"}}]}, {dets_eqc,corrupted,2}, {dets_eqc,'-prop_parallel/0-fun-2-',3}, {eqc_gen,'-f388_0/1-fun-0-',3}, {eqc_gen,gen,3}, {eqc,'-f880_0/1-fun-2-',3}, {eqc_gen,'-f330_0/2-fun-1-',4}, {eqc_gen,f274_0,3}]}} bag 1000 {[{init,{init_state,{state,undefined,bag,[],0}}}, {set,{var,15},{call,dets_eqc,open_file,[dets_table,[{type,bag}]]}}, {set,{var,20},{call,dets,close,[dets_table]}}, {set,{var,21},{call,dets_eqc,open_file,[dets_table,[{type,bag}]]}}], [[{set,{var,22},{call,dets,lookup,[dets_table,0]}}], [{set,{var,24},{call,dets,insert,[dets_table,{0,0}]}}], [{set,{var,25},{call,dets,insert,[dets_table,{0,0}]}}]]} History: [{{set,{var,15},{call,dets_eqc,open_file,[dets_table,[{type,bag}]]}}, dets_table}, {{set,{var,20},{call,dets,close,[dets_table]}},ok}, {{set,{var,21},{call,dets_eqc,open_file,[dets_table,[{type,bag}]]}}, dets_table}] Parallel: [[{set,{var,22},{call,dets,lookup,[dets_table,0]},[]}], [{set,{var,24},{call,dets,insert,[dets_table,{0,0}]},ok}], [{set,{var,25},{call,dets,insert,[dets_table,{0,0}]},ok}]] Res: ok false 2> I'm also attaching a copy of the dets file, just after the test has ended, in case that helps. I'm using QuickCheck version 1.22 to run the test, which can be downloaded from http://quviq-licencer.com/downloads/eqc-1.22.zip. (Note that earlier versions of QuickCheck can't run this example--it makes use of very recent additions). No licence is needed to run the bug() function above. I'm running on an Intel L9400 (Core2Duo). Be interesting to know whether this example fails on other architectures and under other operating systems. John -------------- next part -------------- A non-text attachment was scrubbed... Name: dets_eqc.erl Type: application/octet-stream Size: 7964 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dets_table Type: application/octet-stream Size: 5432 bytes Desc: not available URL: From ingela@REDACTED Fri Sep 24 09:59:24 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Fri, 24 Sep 2010 09:59:24 +0200 Subject: [erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14) In-Reply-To: References: <4C93249F.3040408@erix.ericsson.se> <4C9731E5.2000603@erix.ericsson.se> <4C9765F0.7090801@erix.ericsson.se> <4C989FFC.9060806@erix.ericsson.se> <4C98CA31.4010301@erix.ericsson.se> <4C99B4D7.5020307@erix.ericsson.se> <4C9A009A.4060803@erix.ericsson.se> <4C9B1B88.4020609@erix.ericsson.se> <4C9B4C87.7090605@erix.ericsson.se> Message-ID: <4C9C5A5C.1010500@erix.ericsson.se> Hi! Filipe David Manana wrote: > Regarding the suggestion: > > >> 3) For the verify function, it receives {bad_cert, unknown_ca} when a certificate is self-signed? I would like to distinguish between unknown CAs and >self-signed certificates (certificate signed by the target host). >> > > >>> I think you have a point here we will look in to this. >>> > > Is there any standard (more formal) procedure to submit the suggestion > to the OTP team, or posting to this mailing list is enough? > > cheers > This depends on the type of change you are suggesting. In this case it is a small fairly uncontroversial change that we have already decided to adopt as it is in line with what the old ssl-implementation does. So no need to be more formal and write an EEP - http://www.erlang.org/eep.html It is actually already implemented in the branch ia/ssl-and-public_key/backwards-compatibility/OTP-8858 as the old iplementation does distinguish between the two cases. You can now get {bad_cert, selfsigned_peer} as well as {bad_cert, unknown_ca}. Regards Ingela Erlang/OTP team - Ericsson AB From zerthurd@REDACTED Sun Sep 26 20:15:54 2010 From: zerthurd@REDACTED (Maxim Treskin) Date: Mon, 27 Sep 2010 01:15:54 +0700 Subject: [erlang-bugs] SSH problem in R14B In-Reply-To: <0F93A380-1AB7-4CE3-B0FB-08A7FDFBA360@mac.com> References: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com> <0F93A380-1AB7-4CE3-B0FB-08A7FDFBA360@mac.com> Message-ID: Is this bug will be fixed in otp mainline? On 20 September 2010 21:16, Gene Diveglia wrote: > > Thanks Niclas! That change resolved the problem. > > Kind regards, > > -Gene > > > On Sep 20, 2010, at 9:52 AM, Niclas Eklund wrote: > > > > > Hi! > > > > It seems like that the (deprecated) function public_key:pem_to_der/1 > doesn't return the same thing as in R14A. As a temporary fix, you can change > that function from: > > > > pem_to_der(CertSource) -> > > {ok, Bin} = file:read_file(CertSource), > > pubkey_pem:decode(Bin). > > > > to: > > > > pem_to_der(CertSource) -> > > {ok, Bin} = file:read_file(CertSource), > > {ok, pubkey_pem:decode(Bin)}. > > > > Then it should work. Or you can wait until a fix has been pushed. > > > > Best regards, > > > > Niclas @ Erlang/OTP > > > > On Thu, 16 Sep 2010, Maxim Treskin wrote: > > > >> Yes, have the same on Gentoo Linux amd64 > >> > >> On 16 September 2010 04:37, Gene Diveglia wrote: > >> > >>> > >>> Hi, it appears something has broken with SSH key exchange in R14B. > None of > >>> my ssh based CLI are working in R14B, but were previously working in > R14A > >>> immediately prior to upgrading. I can replicate the problem easily > using > >>> [otp_src]/lib/ssh/examples/ssh_sample_cli.erl. This sample program > works > >>> with R14A under OS X 10.6.4 x86, but will fail if run under R14B. The > ssh > >>> client used in both cases was also on OS X 10.6.4 and was used with > defaults > >>> other than the port number. Standard ssh host key files which are > >>> functional under the OS were used in both cases. I also tried a set of > host > >>> key files generated with a different version of ssh-keygen under linux. > The > >>> error report under R14B follows. > >>> > >>> Kind regards, > >>> > >>> -Gene > >>> > >>> =ERROR REPORT==== 15-Sep-2010::17:18:48 === > >>> ** State machine <0.55.0> terminating > >>> ** Last message in was {tcp,#Port<0.1003>, > >>> > >>> <<0,0,0,140,6,30,0,0,0,128,65,149,33,196,247,233, > >>> > 21,88,218,104,244,10,153,132,125,40,71,44,131, > >>> > >>> 253,22,245,12,59,92,79,134,177,95,51,154,41,176, > >>> > >>> 243,232,208,168,184,12,181,124,38,62,214,81,115, > >>> > >>> 50,11,63,233,1,35,154,219,53,185,15,122,237,207, > >>> > >>> 92,254,52,163,183,160,234,190,135,187,237,54,76, > >>> > 129,219,210,144,186,203,125,92,60,144,43,145, > >>> > >>> 252,215,173,236,140,234,156,165,21,133,116,117, > >>> > >>> 100,130,233,22,62,184,117,253,60,161,185,80,36, > >>> > 18,166,97,155,71,133,192,82,143,61,176,78,177, > >>> 99,138,116,239,183,0,0,0,0,0,0>>} > >>> ** When State == key_exchange > >>> ** Data == {state,tcp,gen_tcp,tcp_closed, > >>> {ssh,server, > >>> {undefined,{{0,0,0,0,0,65535,32512,1},61612}}, > >>> {2,0}, > >>> {2,0}, > >>> "SSH-2.0-OpenSSH_5.2","SSH-2.0-Erlang", > >>> > >>> <<20,12,57,149,244,18,127,223,192,251,128,85,91,196, > >>> > >>> 128,29,110,0,0,0,126,100,105,102,102,105,101,45,104, > >>> > 101,108,108,109,97,110,45,103,114,111,117,112,45, > >>> > >>> 101,120,99,104,97,110,103,101,45,115,104,97,50,53, > >>> > 54,44,100,105,102,102,105,101,45,104,101,108,108, > >>> > >>> 109,97,110,45,103,114,111,117,112,45,101,120,99,104, > >>> > >>> 97,110,103,101,45,115,104,97,49,44,100,105,102,102, > >>> > 105,101,45,104,101,108,108,109,97,110,45,103,114, > >>> > >>> 111,117,112,49,52,45,115,104,97,49,44,100,105,102, > >>> > 102,105,101,45,104,101,108,108,109,97,110,45,103, > >>> > 114,111,117,112,49,45,115,104,97,49,0,0,0,15,115, > >>> > >>> 115,104,45,114,115,97,44,115,115,104,45,100,115,115, > >>> > >>> 0,0,0,157,97,101,115,49,50,56,45,99,116,114,44,97, > >>> > >>> 101,115,49,57,50,45,99,116,114,44,97,101,115,50,53, > >>> > >>> 54,45,99,116,114,44,97,114,99,102,111,117,114,50,53, > >>> > >>> 54,44,97,114,99,102,111,117,114,49,50,56,44,97,101, > >>> > >>> 115,49,50,56,45,99,98,99,44,51,100,101,115,45,99,98, > >>> > >>> 99,44,98,108,111,119,102,105,115,104,45,99,98,99,44, > >>> > >>> 99,97,115,116,49,50,56,45,99,98,99,44,97,101,115,49, > >>> > >>> 57,50,45,99,98,99,44,97,101,115,50,53,54,45,99,98, > >>> > >>> 99,44,97,114,99,102,111,117,114,44,114,105,106,110, > >>> > 100,97,101,108,45,99,98,99,64,108,121,115,97,116, > >>> > >>> 111,114,46,108,105,117,46,115,101,0,0,0,157,97,101, > >>> > >>> 115,49,50,56,45,99,116,114,44,97,101,115,49,57,50, > >>> > >>> 45,99,116,114,44,97,101,115,50,53,54,45,99,116,114, > >>> > >>> 44,97,114,99,102,111,117,114,50,53,54,44,97,114,99, > >>> > >>> 102,111,117,114,49,50,56,44,97,101,115,49,50,56,45, > >>> > 99,98,99,44,51,100,101,115,45,99,98,99,44,98,108, > >>> > 111,119,102,105,115,104,45,99,98,99,44,99,97,115, > >>> > >>> 116,49,50,56,45,99,98,99,44,97,101,115,49,57,50,45, > >>> > >>> 99,98,99,44,97,101,115,50,53,54,45,99,98,99,44,97, > >>> > 114,99,102,111,117,114,44,114,105,106,110,100,97, > >>> > >>> 101,108,45,99,98,99,64,108,121,115,97,116,111,114, > >>> > >>> 46,108,105,117,46,115,101,0,0,0,105,104,109,97,99, > >>> > >>> 45,109,100,53,44,104,109,97,99,45,115,104,97,49,44, > >>> > >>> 117,109,97,99,45,54,52,64,111,112,101,110,115,115, > >>> > >>> 104,46,99,111,109,44,104,109,97,99,45,114,105,112, > >>> > 101,109,100,49,54,48,44,104,109,97,99,45,114,105, > >>> > >>> 112,101,109,100,49,54,48,64,111,112,101,110,115,115, > >>> > >>> 104,46,99,111,109,44,104,109,97,99,45,115,104,97,49, > >>> > >>> 45,57,54,44,104,109,97,99,45,109,100,53,45,57,54,0, > >>> > >>> 0,0,105,104,109,97,99,45,109,100,53,44,104,109,97, > >>> > 99,45,115,104,97,49,44,117,109,97,99,45,54,52,64, > >>> > 111,112,101,110,115,115,104,46,99,111,109,44,104, > >>> > 109,97,99,45,114,105,112,101,109,100,49,54,48,44, > >>> > >>> 104,109,97,99,45,114,105,112,101,109,100,49,54,48, > >>> > >>> 64,111,112,101,110,115,115,104,46,99,111,109,44,104, > >>> > >>> 109,97,99,45,115,104,97,49,45,57,54,44,104,109,97, > >>> > >>> 99,45,109,100,53,45,57,54,0,0,0,26,110,111,110,101, > >>> > >>> 44,122,108,105,98,64,111,112,101,110,115,115,104,46, > >>> > >>> 99,111,109,44,122,108,105,98,0,0,0,26,110,111,110, > >>> > 101,44,122,108,105,98,64,111,112,101,110,115,115, > >>> > >>> 104,46,99,111,109,44,122,108,105,98,0,0,0,0,0,0,0,0, > >>> 0,0,0,0,0>>, > >>> > >>> <<20,38,144,242,6,169,190,51,74,102,5,149,16,239,7,65, > >>> > >>> 57,0,0,0,26,100,105,102,102,105,101,45,104,101,108, > >>> > >>> 108,109,97,110,45,103,114,111,117,112,49,45,115,104, > >>> > >>> 97,49,0,0,0,7,115,115,104,45,100,115,115,0,0,0,19, > >>> > >>> 97,101,115,49,50,56,45,99,98,99,44,51,100,101,115, > >>> > >>> 45,99,98,99,0,0,0,19,97,101,115,49,50,56,45,99,98, > >>> > >>> 99,44,51,100,101,115,45,99,98,99,0,0,0,9,104,109,97, > >>> > 99,45,115,104,97,49,0,0,0,9,104,109,97,99,45,115, > >>> > >>> 104,97,49,0,0,0,9,110,111,110,101,44,122,108,105,98, > >>> > >>> 0,0,0,9,110,111,110,101,44,122,108,105,98,0,0,0,0,0, > >>> 0,0,0,0,0,0,0,0>>, > >>> {alg,'diffie-hellman-group1-sha1','ssh-dss', > >>> 'hmac-sha1','hmac-sha1','aes128-cbc', > >>> 'aes128-cbc',none,none,none,none}, > >>> > >>> undefined,undefined,ssh_file,ssh_io,none,undefined,0, > >>> > none,undefined,0,none,undefined,8,undefined,none, > >>> > >>> undefined,8,undefined,none,undefined,none,undefined, > >>> none,none,true,infinity,undefined,undefined, > >>> undefined, > >>> [{address,"ims"}, > >>> {port,2223}, > >>> {system_dir,"/Users/gene/erl_ssh"}, > >>> {shell,#Fun}, > >>> {role,server}], > >>> 1,1,undefined,undefined,undefined,undefined, > >>> > >>> undefined,"publickey,keyboard_interactive,password", > >>> undefined,undefined}, > >>> #Port<0.1003>,<<>>,<<>>,undefined, > >>> {ssh_msg_kexinit, > >>> > <<127,229,163,177,131,154,163,20,128,32,226,34,154, > >>> 235,187,170>>, > >>> ["diffie-hellman-group1-sha1"], > >>> ["ssh-dss"], > >>> ["aes128-cbc","3des-cbc"], > >>> ["aes128-cbc","3des-cbc"], > >>> ["hmac-sha1"], > >>> ["hmac-sha1"], > >>> ["none","zlib"], > >>> ["none","zlib"], > >>> [],[],false,0}, > >>> false,<0.54.0>,undefined,undefined,undefined, > >>> [{address,"ims"}, > >>> {port,2223}, > >>> {system_dir,"/Users/gene/erl_ssh"}, > >>> {shell,#Fun}, > >>> {role,server}]} > >>> ** Reason for termination = > >>> ** > >>> > {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, > >>> > >>> 87,111,15,213,167,162,93,159,122,170,251,197,236, > >>> > 195,42,174,179,117,37,219,193,70,162,69,63,82, > >>> > >>> 132,149,99,206,90,198,153,34,211,176,14,89,142, > >>> > >>> 220,203,9,122,34,99,12,156,119,19,117,186,2,233, > >>> > >>> 151,22,31,96,153,210,219,121,225,207,231,39,246, > >>> > >>> 64,108,176,211,77,252,98,34,16,210,73,17,189,187, > >>> > >>> 193,111,191,143,115,49,60,159,218,245,67,241,2, > >>> > 130,232,145,217,10,236,86,139,125,238,252,102, > >>> > >>> 246,213,110,249,125,80,182,210,55,229,163,214,91, > >>> > >>> 112,60,117,209,220,205,2,21,0,159,83,129,175,245, > >>> > 131,186,139,165,18,35,133,43,148,124,202,31,9, > >>> > >>> 142,189,2,129,128,107,72,221,121,89,226,22,151, > >>> > >>> 35,105,202,173,197,168,100,60,58,6,23,223,9,121, > >>> > >>> 175,53,248,135,5,120,183,100,107,135,102,219,116, > >>> > >>> 63,213,17,149,118,142,19,143,204,168,236,49,165, > >>> > >>> 1,136,195,111,248,199,182,253,234,46,173,28,30, > >>> > >>> 114,240,8,77,176,107,184,41,108,183,172,165,202, > >>> > 3,90,166,69,76,202,187,58,133,192,38,1,38,110, > >>> > >>> 212,36,18,35,149,58,218,69,134,143,42,1,174,19, > >>> > >>> 233,236,61,165,187,157,254,168,163,243,248,227, > >>> > >>> 110,122,213,72,107,214,220,212,99,245,106,120,91, > >>> > >>> 131,2,129,128,113,214,224,173,14,157,34,113,59, > >>> > >>> 116,57,129,233,210,114,12,213,159,133,106,34,130, > >>> > >>> 102,199,157,241,226,84,186,245,237,230,106,6,231, > >>> > >>> 231,140,208,106,53,74,56,77,48,92,112,47,91,236, > >>> > 135,107,16,8,93,241,130,5,118,126,197,127,233, > >>> > >>> 238,199,226,7,79,225,193,139,174,87,11,168,190, > >>> > >>> 220,127,150,135,210,198,209,242,104,166,143,236, > >>> > >>> 18,125,22,64,26,53,139,45,219,45,144,236,245,193, > >>> > >>> 127,152,100,103,179,152,156,208,18,94,96,227,44, > >>> > >>> 151,136,194,77,114,12,70,223,143,194,196,204,101, > >>> > >>> 184,2,20,43,222,65,115,20,238,35,218,102,176,95, > >>> 196,101,68,47,163,229,153,49,118>>, > >>> not_encrypted}]} > >>> > >>> =ERROR REPORT==== 15-Sep-2010::17:18:48 === > >>> ** Generic server <0.52.0> terminating > >>> ** Last message in was {'EXIT',<0.55.0>, > >>> {error, > >>> [{'DSAPrivateKey', > >>> > >>> <<48,130,1,186,2,1,0,2,129,129,0,170,223, > >>> > >>> 146,206,87,111,15,213,167,162,93,159,122, > >>> > 170,251,197,236,195,42,174,179,117,37, > >>> > >>> 219,193,70,162,69,63,82,132,149,99,206, > >>> > >>> 90,198,153,34,211,176,14,89,142,220,203, > >>> > >>> 9,122,34,99,12,156,119,19,117,186,2,233, > >>> > >>> 151,22,31,96,153,210,219,121,225,207,231, > >>> > 39,246,64,108,176,211,77,252,98,34,16, > >>> > >>> 210,73,17,189,187,193,111,191,143,115,49, > >>> > >>> 60,159,218,245,67,241,2,130,232,145,217, > >>> > 10,236,86,139,125,238,252,102,246,213, > >>> > >>> 110,249,125,80,182,210,55,229,163,214,91, > >>> > >>> 112,60,117,209,220,205,2,21,0,159,83,129, > >>> > >>> 175,245,131,186,139,165,18,35,133,43,148, > >>> > 124,202,31,9,142,189,2,129,128,107,72, > >>> > >>> 221,121,89,226,22,151,35,105,202,173,197, > >>> > >>> 168,100,60,58,6,23,223,9,121,175,53,248, > >>> > >>> 135,5,120,183,100,107,135,102,219,116,63, > >>> > >>> 213,17,149,118,142,19,143,204,168,236,49, > >>> > >>> 165,1,136,195,111,248,199,182,253,234,46, > >>> > 173,28,30,114,240,8,77,176,107,184,41, > >>> > >>> 108,183,172,165,202,3,90,166,69,76,202, > >>> > >>> 187,58,133,192,38,1,38,110,212,36,18,35, > >>> > 149,58,218,69,134,143,42,1,174,19,233, > >>> > >>> 236,61,165,187,157,254,168,163,243,248, > >>> > 227,110,122,213,72,107,214,220,212,99, > >>> > >>> 245,106,120,91,131,2,129,128,113,214,224, > >>> > >>> 173,14,157,34,113,59,116,57,129,233,210, > >>> > 114,12,213,159,133,106,34,130,102,199, > >>> > >>> 157,241,226,84,186,245,237,230,106,6,231, > >>> > >>> 231,140,208,106,53,74,56,77,48,92,112,47, > >>> > >>> 91,236,135,107,16,8,93,241,130,5,118,126, > >>> > >>> 197,127,233,238,199,226,7,79,225,193,139, > >>> > 174,87,11,168,190,220,127,150,135,210, > >>> > >>> 198,209,242,104,166,143,236,18,125,22,64, > >>> > >>> 26,53,139,45,219,45,144,236,245,193,127, > >>> > >>> 152,100,103,179,152,156,208,18,94,96,227, > >>> > >>> 44,151,136,194,77,114,12,70,223,143,194, > >>> > 196,204,101,184,2,20,43,222,65,115,20, > >>> > >>> 238,35,218,102,176,95,196,101,68,47,163, > >>> 229,153,49,118>>, > >>> not_encrypted}]}} > >>> ** When Server state == {state,server,<0.54.0>,<0.55.0>,undefined} > >>> ** Reason for termination == > >>> ** > >>> > {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, > >>> > >>> 87,111,15,213,167,162,93,159,122,170,251,197,236, > >>> > 195,42,174,179,117,37,219,193,70,162,69,63,82, > >>> > >>> 132,149,99,206,90,198,153,34,211,176,14,89,142, > >>> > >>> 220,203,9,122,34,99,12,156,119,19,117,186,2,233, > >>> > >>> 151,22,31,96,153,210,219,121,225,207,231,39,246, > >>> > >>> 64,108,176,211,77,252,98,34,16,210,73,17,189,187, > >>> > >>> 193,111,191,143,115,49,60,159,218,245,67,241,2, > >>> > 130,232,145,217,10,236,86,139,125,238,252,102, > >>> > >>> 246,213,110,249,125,80,182,210,55,229,163,214,91, > >>> > >>> 112,60,117,209,220,205,2,21,0,159,83,129,175,245, > >>> > 131,186,139,165,18,35,133,43,148,124,202,31,9, > >>> > >>> 142,189,2,129,128,107,72,221,121,89,226,22,151, > >>> > >>> 35,105,202,173,197,168,100,60,58,6,23,223,9,121, > >>> > >>> 175,53,248,135,5,120,183,100,107,135,102,219,116, > >>> > >>> 63,213,17,149,118,142,19,143,204,168,236,49,165, > >>> > >>> 1,136,195,111,248,199,182,253,234,46,173,28,30, > >>> > >>> 114,240,8,77,176,107,184,41,108,183,172,165,202, > >>> > 3,90,166,69,76,202,187,58,133,192,38,1,38,110, > >>> > >>> 212,36,18,35,149,58,218,69,134,143,42,1,174,19, > >>> > >>> 233,236,61,165,187,157,254,168,163,243,248,227, > >>> > >>> 110,122,213,72,107,214,220,212,99,245,106,120,91, > >>> > >>> 131,2,129,128,113,214,224,173,14,157,34,113,59, > >>> > >>> 116,57,129,233,210,114,12,213,159,133,106,34,130, > >>> > >>> 102,199,157,241,226,84,186,245,237,230,106,6,231, > >>> > >>> 231,140,208,106,53,74,56,77,48,92,112,47,91,236, > >>> > 135,107,16,8,93,241,130,5,118,126,197,127,233, > >>> > >>> 238,199,226,7,79,225,193,139,174,87,11,168,190, > >>> > >>> 220,127,150,135,210,198,209,242,104,166,143,236, > >>> > >>> 18,125,22,64,26,53,139,45,219,45,144,236,245,193, > >>> > >>> 127,152,100,103,179,152,156,208,18,94,96,227,44, > >>> > >>> 151,136,194,77,114,12,70,223,143,194,196,204,101, > >>> > >>> 184,2,20,43,222,65,115,20,238,35,218,102,176,95, > >>> 196,101,68,47,163,229,153,49,118>>, > >>> not_encrypted}]} > >>> > >>> > >>> ________________________________________________________________ > >>> erlang-bugs (at) erlang.org mailing list. > >>> See http://www.erlang.org/faq.html > >>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > >>> > >>> > >> > >> > >> -- > >> Maxim Treskin > >> > > > > > > > > ________________________________________________________________ > > erlang-bugs (at) erlang.org mailing list. > > See http://www.erlang.org/faq.html > > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- Maxim Treskin From zerthurd@REDACTED Sun Sep 26 20:57:43 2010 From: zerthurd@REDACTED (Maxim Treskin) Date: Mon, 27 Sep 2010 01:57:43 +0700 Subject: [erlang-patces] SSH problem in R14B: using deprecated function with unexpected return value Message-ID: On 27 September 2010 01:15, Maxim Treskin wrote: > Is this bug will be fixed in otp mainline? > > > On 20 September 2010 21:16, Gene Diveglia wrote: > >> >> Thanks Niclas! That change resolved the problem. >> >> Kind regards, >> >> -Gene >> >> >> On Sep 20, 2010, at 9:52 AM, Niclas Eklund wrote: >> >> > >> > Hi! >> > >> > It seems like that the (deprecated) function public_key:pem_to_der/1 >> doesn't return the same thing as in R14A. As a temporary fix, you can change >> that function from: >> > >> > pem_to_der(CertSource) -> >> > {ok, Bin} = file:read_file(CertSource), >> > pubkey_pem:decode(Bin). >> > >> > to: >> > >> > pem_to_der(CertSource) -> >> > {ok, Bin} = file:read_file(CertSource), >> > {ok, pubkey_pem:decode(Bin)}. >> > >> > Then it should work. Or you can wait until a fix has been pushed. >> > >> > Best regards, >> > >> > Niclas @ Erlang/OTP >> > >> > On Thu, 16 Sep 2010, Maxim Treskin wrote: >> > >> >> Yes, have the same on Gentoo Linux amd64 >> >> >> >> On 16 September 2010 04:37, Gene Diveglia wrote: >> >> >> >>> >> >>> Hi, it appears something has broken with SSH key exchange in R14B. >> None of >> >>> my ssh based CLI are working in R14B, but were previously working in >> R14A >> >>> immediately prior to upgrading. I can replicate the problem easily >> using >> >>> [otp_src]/lib/ssh/examples/ssh_sample_cli.erl. This sample program >> works >> >>> with R14A under OS X 10.6.4 x86, but will fail if run under R14B. The >> ssh >> >>> client used in both cases was also on OS X 10.6.4 and was used with >> defaults >> >>> other than the port number. Standard ssh host key files which are >> >>> functional under the OS were used in both cases. I also tried a set >> of host >> >>> key files generated with a different version of ssh-keygen under >> linux. The >> >>> error report under R14B follows. >> >>> >> >>> Kind regards, >> >>> >> >>> -Gene >> >>> >> >>> =ERROR REPORT==== 15-Sep-2010::17:18:48 === >> >>> ** State machine <0.55.0> terminating >> >>> ** Last message in was {tcp,#Port<0.1003>, >> >>> >> >>> <<0,0,0,140,6,30,0,0,0,128,65,149,33,196,247,233, >> >>> >> 21,88,218,104,244,10,153,132,125,40,71,44,131, >> >>> >> >>> 253,22,245,12,59,92,79,134,177,95,51,154,41,176, >> >>> >> >>> 243,232,208,168,184,12,181,124,38,62,214,81,115, >> >>> >> >>> 50,11,63,233,1,35,154,219,53,185,15,122,237,207, >> >>> >> >>> 92,254,52,163,183,160,234,190,135,187,237,54,76, >> >>> >> 129,219,210,144,186,203,125,92,60,144,43,145, >> >>> >> >>> 252,215,173,236,140,234,156,165,21,133,116,117, >> >>> >> >>> 100,130,233,22,62,184,117,253,60,161,185,80,36, >> >>> >> 18,166,97,155,71,133,192,82,143,61,176,78,177, >> >>> 99,138,116,239,183,0,0,0,0,0,0>>} >> >>> ** When State == key_exchange >> >>> ** Data == {state,tcp,gen_tcp,tcp_closed, >> >>> {ssh,server, >> >>> {undefined,{{0,0,0,0,0,65535,32512,1},61612}}, >> >>> {2,0}, >> >>> {2,0}, >> >>> "SSH-2.0-OpenSSH_5.2","SSH-2.0-Erlang", >> >>> >> >>> <<20,12,57,149,244,18,127,223,192,251,128,85,91,196, >> >>> >> >>> 128,29,110,0,0,0,126,100,105,102,102,105,101,45,104, >> >>> >> 101,108,108,109,97,110,45,103,114,111,117,112,45, >> >>> >> >>> 101,120,99,104,97,110,103,101,45,115,104,97,50,53, >> >>> >> 54,44,100,105,102,102,105,101,45,104,101,108,108, >> >>> >> >>> 109,97,110,45,103,114,111,117,112,45,101,120,99,104, >> >>> >> >>> 97,110,103,101,45,115,104,97,49,44,100,105,102,102, >> >>> >> 105,101,45,104,101,108,108,109,97,110,45,103,114, >> >>> >> >>> 111,117,112,49,52,45,115,104,97,49,44,100,105,102, >> >>> >> 102,105,101,45,104,101,108,108,109,97,110,45,103, >> >>> >> 114,111,117,112,49,45,115,104,97,49,0,0,0,15,115, >> >>> >> >>> 115,104,45,114,115,97,44,115,115,104,45,100,115,115, >> >>> >> >>> 0,0,0,157,97,101,115,49,50,56,45,99,116,114,44,97, >> >>> >> >>> 101,115,49,57,50,45,99,116,114,44,97,101,115,50,53, >> >>> >> >>> 54,45,99,116,114,44,97,114,99,102,111,117,114,50,53, >> >>> >> >>> 54,44,97,114,99,102,111,117,114,49,50,56,44,97,101, >> >>> >> >>> 115,49,50,56,45,99,98,99,44,51,100,101,115,45,99,98, >> >>> >> >>> 99,44,98,108,111,119,102,105,115,104,45,99,98,99,44, >> >>> >> >>> 99,97,115,116,49,50,56,45,99,98,99,44,97,101,115,49, >> >>> >> >>> 57,50,45,99,98,99,44,97,101,115,50,53,54,45,99,98, >> >>> >> >>> 99,44,97,114,99,102,111,117,114,44,114,105,106,110, >> >>> >> 100,97,101,108,45,99,98,99,64,108,121,115,97,116, >> >>> >> >>> 111,114,46,108,105,117,46,115,101,0,0,0,157,97,101, >> >>> >> >>> 115,49,50,56,45,99,116,114,44,97,101,115,49,57,50, >> >>> >> >>> 45,99,116,114,44,97,101,115,50,53,54,45,99,116,114, >> >>> >> >>> 44,97,114,99,102,111,117,114,50,53,54,44,97,114,99, >> >>> >> >>> 102,111,117,114,49,50,56,44,97,101,115,49,50,56,45, >> >>> >> 99,98,99,44,51,100,101,115,45,99,98,99,44,98,108, >> >>> >> 111,119,102,105,115,104,45,99,98,99,44,99,97,115, >> >>> >> >>> 116,49,50,56,45,99,98,99,44,97,101,115,49,57,50,45, >> >>> >> >>> 99,98,99,44,97,101,115,50,53,54,45,99,98,99,44,97, >> >>> >> 114,99,102,111,117,114,44,114,105,106,110,100,97, >> >>> >> >>> 101,108,45,99,98,99,64,108,121,115,97,116,111,114, >> >>> >> >>> 46,108,105,117,46,115,101,0,0,0,105,104,109,97,99, >> >>> >> >>> 45,109,100,53,44,104,109,97,99,45,115,104,97,49,44, >> >>> >> >>> 117,109,97,99,45,54,52,64,111,112,101,110,115,115, >> >>> >> >>> 104,46,99,111,109,44,104,109,97,99,45,114,105,112, >> >>> >> 101,109,100,49,54,48,44,104,109,97,99,45,114,105, >> >>> >> >>> 112,101,109,100,49,54,48,64,111,112,101,110,115,115, >> >>> >> >>> 104,46,99,111,109,44,104,109,97,99,45,115,104,97,49, >> >>> >> >>> 45,57,54,44,104,109,97,99,45,109,100,53,45,57,54,0, >> >>> >> >>> 0,0,105,104,109,97,99,45,109,100,53,44,104,109,97, >> >>> >> 99,45,115,104,97,49,44,117,109,97,99,45,54,52,64, >> >>> >> 111,112,101,110,115,115,104,46,99,111,109,44,104, >> >>> >> 109,97,99,45,114,105,112,101,109,100,49,54,48,44, >> >>> >> >>> 104,109,97,99,45,114,105,112,101,109,100,49,54,48, >> >>> >> >>> 64,111,112,101,110,115,115,104,46,99,111,109,44,104, >> >>> >> >>> 109,97,99,45,115,104,97,49,45,57,54,44,104,109,97, >> >>> >> >>> 99,45,109,100,53,45,57,54,0,0,0,26,110,111,110,101, >> >>> >> >>> 44,122,108,105,98,64,111,112,101,110,115,115,104,46, >> >>> >> >>> 99,111,109,44,122,108,105,98,0,0,0,26,110,111,110, >> >>> >> 101,44,122,108,105,98,64,111,112,101,110,115,115, >> >>> >> >>> 104,46,99,111,109,44,122,108,105,98,0,0,0,0,0,0,0,0, >> >>> 0,0,0,0,0>>, >> >>> >> >>> <<20,38,144,242,6,169,190,51,74,102,5,149,16,239,7,65, >> >>> >> >>> 57,0,0,0,26,100,105,102,102,105,101,45,104,101,108, >> >>> >> >>> 108,109,97,110,45,103,114,111,117,112,49,45,115,104, >> >>> >> >>> 97,49,0,0,0,7,115,115,104,45,100,115,115,0,0,0,19, >> >>> >> >>> 97,101,115,49,50,56,45,99,98,99,44,51,100,101,115, >> >>> >> >>> 45,99,98,99,0,0,0,19,97,101,115,49,50,56,45,99,98, >> >>> >> >>> 99,44,51,100,101,115,45,99,98,99,0,0,0,9,104,109,97, >> >>> >> 99,45,115,104,97,49,0,0,0,9,104,109,97,99,45,115, >> >>> >> >>> 104,97,49,0,0,0,9,110,111,110,101,44,122,108,105,98, >> >>> >> >>> 0,0,0,9,110,111,110,101,44,122,108,105,98,0,0,0,0,0, >> >>> 0,0,0,0,0,0,0,0>>, >> >>> {alg,'diffie-hellman-group1-sha1','ssh-dss', >> >>> 'hmac-sha1','hmac-sha1','aes128-cbc', >> >>> 'aes128-cbc',none,none,none,none}, >> >>> >> >>> undefined,undefined,ssh_file,ssh_io,none,undefined,0, >> >>> >> none,undefined,0,none,undefined,8,undefined,none, >> >>> >> >>> undefined,8,undefined,none,undefined,none,undefined, >> >>> none,none,true,infinity,undefined,undefined, >> >>> undefined, >> >>> [{address,"ims"}, >> >>> {port,2223}, >> >>> {system_dir,"/Users/gene/erl_ssh"}, >> >>> {shell,#Fun}, >> >>> {role,server}], >> >>> 1,1,undefined,undefined,undefined,undefined, >> >>> >> >>> undefined,"publickey,keyboard_interactive,password", >> >>> undefined,undefined}, >> >>> #Port<0.1003>,<<>>,<<>>,undefined, >> >>> {ssh_msg_kexinit, >> >>> >> <<127,229,163,177,131,154,163,20,128,32,226,34,154, >> >>> 235,187,170>>, >> >>> ["diffie-hellman-group1-sha1"], >> >>> ["ssh-dss"], >> >>> ["aes128-cbc","3des-cbc"], >> >>> ["aes128-cbc","3des-cbc"], >> >>> ["hmac-sha1"], >> >>> ["hmac-sha1"], >> >>> ["none","zlib"], >> >>> ["none","zlib"], >> >>> [],[],false,0}, >> >>> false,<0.54.0>,undefined,undefined,undefined, >> >>> [{address,"ims"}, >> >>> {port,2223}, >> >>> {system_dir,"/Users/gene/erl_ssh"}, >> >>> {shell,#Fun}, >> >>> {role,server}]} >> >>> ** Reason for termination = >> >>> ** >> >>> >> {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, >> >>> >> >>> 87,111,15,213,167,162,93,159,122,170,251,197,236, >> >>> >> 195,42,174,179,117,37,219,193,70,162,69,63,82, >> >>> >> >>> 132,149,99,206,90,198,153,34,211,176,14,89,142, >> >>> >> >>> 220,203,9,122,34,99,12,156,119,19,117,186,2,233, >> >>> >> >>> 151,22,31,96,153,210,219,121,225,207,231,39,246, >> >>> >> >>> 64,108,176,211,77,252,98,34,16,210,73,17,189,187, >> >>> >> >>> 193,111,191,143,115,49,60,159,218,245,67,241,2, >> >>> >> 130,232,145,217,10,236,86,139,125,238,252,102, >> >>> >> >>> 246,213,110,249,125,80,182,210,55,229,163,214,91, >> >>> >> >>> 112,60,117,209,220,205,2,21,0,159,83,129,175,245, >> >>> >> 131,186,139,165,18,35,133,43,148,124,202,31,9, >> >>> >> >>> 142,189,2,129,128,107,72,221,121,89,226,22,151, >> >>> >> >>> 35,105,202,173,197,168,100,60,58,6,23,223,9,121, >> >>> >> >>> 175,53,248,135,5,120,183,100,107,135,102,219,116, >> >>> >> >>> 63,213,17,149,118,142,19,143,204,168,236,49,165, >> >>> >> >>> 1,136,195,111,248,199,182,253,234,46,173,28,30, >> >>> >> >>> 114,240,8,77,176,107,184,41,108,183,172,165,202, >> >>> >> 3,90,166,69,76,202,187,58,133,192,38,1,38,110, >> >>> >> >>> 212,36,18,35,149,58,218,69,134,143,42,1,174,19, >> >>> >> >>> 233,236,61,165,187,157,254,168,163,243,248,227, >> >>> >> >>> 110,122,213,72,107,214,220,212,99,245,106,120,91, >> >>> >> >>> 131,2,129,128,113,214,224,173,14,157,34,113,59, >> >>> >> >>> 116,57,129,233,210,114,12,213,159,133,106,34,130, >> >>> >> >>> 102,199,157,241,226,84,186,245,237,230,106,6,231, >> >>> >> >>> 231,140,208,106,53,74,56,77,48,92,112,47,91,236, >> >>> >> 135,107,16,8,93,241,130,5,118,126,197,127,233, >> >>> >> >>> 238,199,226,7,79,225,193,139,174,87,11,168,190, >> >>> >> >>> 220,127,150,135,210,198,209,242,104,166,143,236, >> >>> >> >>> 18,125,22,64,26,53,139,45,219,45,144,236,245,193, >> >>> >> >>> 127,152,100,103,179,152,156,208,18,94,96,227,44, >> >>> >> >>> 151,136,194,77,114,12,70,223,143,194,196,204,101, >> >>> >> >>> 184,2,20,43,222,65,115,20,238,35,218,102,176,95, >> >>> 196,101,68,47,163,229,153,49,118>>, >> >>> not_encrypted}]} >> >>> >> >>> =ERROR REPORT==== 15-Sep-2010::17:18:48 === >> >>> ** Generic server <0.52.0> terminating >> >>> ** Last message in was {'EXIT',<0.55.0>, >> >>> {error, >> >>> [{'DSAPrivateKey', >> >>> >> >>> <<48,130,1,186,2,1,0,2,129,129,0,170,223, >> >>> >> >>> 146,206,87,111,15,213,167,162,93,159,122, >> >>> >> 170,251,197,236,195,42,174,179,117,37, >> >>> >> >>> 219,193,70,162,69,63,82,132,149,99,206, >> >>> >> >>> 90,198,153,34,211,176,14,89,142,220,203, >> >>> >> >>> 9,122,34,99,12,156,119,19,117,186,2,233, >> >>> >> >>> 151,22,31,96,153,210,219,121,225,207,231, >> >>> >> 39,246,64,108,176,211,77,252,98,34,16, >> >>> >> >>> 210,73,17,189,187,193,111,191,143,115,49, >> >>> >> >>> 60,159,218,245,67,241,2,130,232,145,217, >> >>> >> 10,236,86,139,125,238,252,102,246,213, >> >>> >> >>> 110,249,125,80,182,210,55,229,163,214,91, >> >>> >> >>> 112,60,117,209,220,205,2,21,0,159,83,129, >> >>> >> >>> 175,245,131,186,139,165,18,35,133,43,148, >> >>> >> 124,202,31,9,142,189,2,129,128,107,72, >> >>> >> >>> 221,121,89,226,22,151,35,105,202,173,197, >> >>> >> >>> 168,100,60,58,6,23,223,9,121,175,53,248, >> >>> >> >>> 135,5,120,183,100,107,135,102,219,116,63, >> >>> >> >>> 213,17,149,118,142,19,143,204,168,236,49, >> >>> >> >>> 165,1,136,195,111,248,199,182,253,234,46, >> >>> >> 173,28,30,114,240,8,77,176,107,184,41, >> >>> >> >>> 108,183,172,165,202,3,90,166,69,76,202, >> >>> >> >>> 187,58,133,192,38,1,38,110,212,36,18,35, >> >>> >> 149,58,218,69,134,143,42,1,174,19,233, >> >>> >> >>> 236,61,165,187,157,254,168,163,243,248, >> >>> >> 227,110,122,213,72,107,214,220,212,99, >> >>> >> >>> 245,106,120,91,131,2,129,128,113,214,224, >> >>> >> >>> 173,14,157,34,113,59,116,57,129,233,210, >> >>> >> 114,12,213,159,133,106,34,130,102,199, >> >>> >> >>> 157,241,226,84,186,245,237,230,106,6,231, >> >>> >> >>> 231,140,208,106,53,74,56,77,48,92,112,47, >> >>> >> >>> 91,236,135,107,16,8,93,241,130,5,118,126, >> >>> >> >>> 197,127,233,238,199,226,7,79,225,193,139, >> >>> >> 174,87,11,168,190,220,127,150,135,210, >> >>> >> >>> 198,209,242,104,166,143,236,18,125,22,64, >> >>> >> >>> 26,53,139,45,219,45,144,236,245,193,127, >> >>> >> >>> 152,100,103,179,152,156,208,18,94,96,227, >> >>> >> >>> 44,151,136,194,77,114,12,70,223,143,194, >> >>> >> 196,204,101,184,2,20,43,222,65,115,20, >> >>> >> >>> 238,35,218,102,176,95,196,101,68,47,163, >> >>> 229,153,49,118>>, >> >>> not_encrypted}]}} >> >>> ** When Server state == {state,server,<0.54.0>,<0.55.0>,undefined} >> >>> ** Reason for termination == >> >>> ** >> >>> >> {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, >> >>> >> >>> 87,111,15,213,167,162,93,159,122,170,251,197,236, >> >>> >> 195,42,174,179,117,37,219,193,70,162,69,63,82, >> >>> >> >>> 132,149,99,206,90,198,153,34,211,176,14,89,142, >> >>> >> >>> 220,203,9,122,34,99,12,156,119,19,117,186,2,233, >> >>> >> >>> 151,22,31,96,153,210,219,121,225,207,231,39,246, >> >>> >> >>> 64,108,176,211,77,252,98,34,16,210,73,17,189,187, >> >>> >> >>> 193,111,191,143,115,49,60,159,218,245,67,241,2, >> >>> >> 130,232,145,217,10,236,86,139,125,238,252,102, >> >>> >> >>> 246,213,110,249,125,80,182,210,55,229,163,214,91, >> >>> >> >>> 112,60,117,209,220,205,2,21,0,159,83,129,175,245, >> >>> >> 131,186,139,165,18,35,133,43,148,124,202,31,9, >> >>> >> >>> 142,189,2,129,128,107,72,221,121,89,226,22,151, >> >>> >> >>> 35,105,202,173,197,168,100,60,58,6,23,223,9,121, >> >>> >> >>> 175,53,248,135,5,120,183,100,107,135,102,219,116, >> >>> >> >>> 63,213,17,149,118,142,19,143,204,168,236,49,165, >> >>> >> >>> 1,136,195,111,248,199,182,253,234,46,173,28,30, >> >>> >> >>> 114,240,8,77,176,107,184,41,108,183,172,165,202, >> >>> >> 3,90,166,69,76,202,187,58,133,192,38,1,38,110, >> >>> >> >>> 212,36,18,35,149,58,218,69,134,143,42,1,174,19, >> >>> >> >>> 233,236,61,165,187,157,254,168,163,243,248,227, >> >>> >> >>> 110,122,213,72,107,214,220,212,99,245,106,120,91, >> >>> >> >>> 131,2,129,128,113,214,224,173,14,157,34,113,59, >> >>> >> >>> 116,57,129,233,210,114,12,213,159,133,106,34,130, >> >>> >> >>> 102,199,157,241,226,84,186,245,237,230,106,6,231, >> >>> >> >>> 231,140,208,106,53,74,56,77,48,92,112,47,91,236, >> >>> >> 135,107,16,8,93,241,130,5,118,126,197,127,233, >> >>> >> >>> 238,199,226,7,79,225,193,139,174,87,11,168,190, >> >>> >> >>> 220,127,150,135,210,198,209,242,104,166,143,236, >> >>> >> >>> 18,125,22,64,26,53,139,45,219,45,144,236,245,193, >> >>> >> >>> 127,152,100,103,179,152,156,208,18,94,96,227,44, >> >>> >> >>> 151,136,194,77,114,12,70,223,143,194,196,204,101, >> >>> >> >>> 184,2,20,43,222,65,115,20,238,35,218,102,176,95, >> >>> 196,101,68,47,163,229,153,49,118>>, >> >>> not_encrypted}]} >> >>> >> >>> >> >>> ________________________________________________________________ >> >>> erlang-bugs (at) erlang.org mailing list. >> >>> See http://www.erlang.org/faq.html >> >>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> >>> >> >>> >> >> >> >> >> >> -- >> >> Maxim Treskin >> >> >> > >> > >> > >> > ________________________________________________________________ >> > erlang-bugs (at) erlang.org mailing list. >> > See http://www.erlang.org/faq.html >> > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> > >> >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> >> > > > -- > Maxim Treskin > -- Maxim Treskin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Do-not-use-deprecated-public_key-pem_to_der-2-with-u.patch Type: application/octet-stream Size: 1116 bytes Desc: not available URL: From ingela@REDACTED Mon Sep 27 10:36:14 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 27 Sep 2010 10:36:14 +0200 Subject: [erlang-bugs] SSH problem in R14B In-Reply-To: References: <8FE0EC49-FF79-4ED3-AFF7-6D0C083DF193@mac.com> <0F93A380-1AB7-4CE3-B0FB-08A7FDFBA360@mac.com> Message-ID: <4CA0577E.7090300@erix.ericsson.se> Hi! Maxim Treskin wrote: > Is this bug will be fixed in otp mainline? > > The code containing this fix has now been pushed to our dev branch and will soon be visible at github. (Later today that should be). Regards Ingela Erlang OTP/Team - Ericsson AB > On 20 September 2010 21:16, Gene Diveglia wrote: > > >> Thanks Niclas! That change resolved the problem. >> >> Kind regards, >> >> -Gene >> >> >> On Sep 20, 2010, at 9:52 AM, Niclas Eklund wrote: >> >> >>> Hi! >>> >>> It seems like that the (deprecated) function public_key:pem_to_der/1 >>> >> doesn't return the same thing as in R14A. As a temporary fix, you can change >> that function from: >> >>> pem_to_der(CertSource) -> >>> {ok, Bin} = file:read_file(CertSource), >>> pubkey_pem:decode(Bin). >>> >>> to: >>> >>> pem_to_der(CertSource) -> >>> {ok, Bin} = file:read_file(CertSource), >>> {ok, pubkey_pem:decode(Bin)}. >>> >>> Then it should work. Or you can wait until a fix has been pushed. >>> >>> Best regards, >>> >>> Niclas @ Erlang/OTP >>> >>> On Thu, 16 Sep 2010, Maxim Treskin wrote: >>> >>> >>>> Yes, have the same on Gentoo Linux amd64 >>>> >>>> On 16 September 2010 04:37, Gene Diveglia wrote: >>>> >>>> >>>>> Hi, it appears something has broken with SSH key exchange in R14B. >>>>> >> None of >> >>>>> my ssh based CLI are working in R14B, but were previously working in >>>>> >> R14A >> >>>>> immediately prior to upgrading. I can replicate the problem easily >>>>> >> using >> >>>>> [otp_src]/lib/ssh/examples/ssh_sample_cli.erl. This sample program >>>>> >> works >> >>>>> with R14A under OS X 10.6.4 x86, but will fail if run under R14B. The >>>>> >> ssh >> >>>>> client used in both cases was also on OS X 10.6.4 and was used with >>>>> >> defaults >> >>>>> other than the port number. Standard ssh host key files which are >>>>> functional under the OS were used in both cases. I also tried a set of >>>>> >> host >> >>>>> key files generated with a different version of ssh-keygen under linux. >>>>> >> The >> >>>>> error report under R14B follows. >>>>> >>>>> Kind regards, >>>>> >>>>> -Gene >>>>> >>>>> =ERROR REPORT==== 15-Sep-2010::17:18:48 === >>>>> ** State machine <0.55.0> terminating >>>>> ** Last message in was {tcp,#Port<0.1003>, >>>>> >>>>> <<0,0,0,140,6,30,0,0,0,128,65,149,33,196,247,233, >>>>> >>>>> >> 21,88,218,104,244,10,153,132,125,40,71,44,131, >> >>>>> 253,22,245,12,59,92,79,134,177,95,51,154,41,176, >>>>> >>>>> 243,232,208,168,184,12,181,124,38,62,214,81,115, >>>>> >>>>> 50,11,63,233,1,35,154,219,53,185,15,122,237,207, >>>>> >>>>> 92,254,52,163,183,160,234,190,135,187,237,54,76, >>>>> >>>>> >> 129,219,210,144,186,203,125,92,60,144,43,145, >> >>>>> 252,215,173,236,140,234,156,165,21,133,116,117, >>>>> >>>>> 100,130,233,22,62,184,117,253,60,161,185,80,36, >>>>> >>>>> >> 18,166,97,155,71,133,192,82,143,61,176,78,177, >> >>>>> 99,138,116,239,183,0,0,0,0,0,0>>} >>>>> ** When State == key_exchange >>>>> ** Data == {state,tcp,gen_tcp,tcp_closed, >>>>> {ssh,server, >>>>> {undefined,{{0,0,0,0,0,65535,32512,1},61612}}, >>>>> {2,0}, >>>>> {2,0}, >>>>> "SSH-2.0-OpenSSH_5.2","SSH-2.0-Erlang", >>>>> >>>>> <<20,12,57,149,244,18,127,223,192,251,128,85,91,196, >>>>> >>>>> 128,29,110,0,0,0,126,100,105,102,102,105,101,45,104, >>>>> >>>>> >> 101,108,108,109,97,110,45,103,114,111,117,112,45, >> >>>>> 101,120,99,104,97,110,103,101,45,115,104,97,50,53, >>>>> >>>>> >> 54,44,100,105,102,102,105,101,45,104,101,108,108, >> >>>>> 109,97,110,45,103,114,111,117,112,45,101,120,99,104, >>>>> >>>>> 97,110,103,101,45,115,104,97,49,44,100,105,102,102, >>>>> >>>>> >> 105,101,45,104,101,108,108,109,97,110,45,103,114, >> >>>>> 111,117,112,49,52,45,115,104,97,49,44,100,105,102, >>>>> >>>>> >> 102,105,101,45,104,101,108,108,109,97,110,45,103, >> >> 114,111,117,112,49,45,115,104,97,49,0,0,0,15,115, >> >>>>> 115,104,45,114,115,97,44,115,115,104,45,100,115,115, >>>>> >>>>> 0,0,0,157,97,101,115,49,50,56,45,99,116,114,44,97, >>>>> >>>>> 101,115,49,57,50,45,99,116,114,44,97,101,115,50,53, >>>>> >>>>> 54,45,99,116,114,44,97,114,99,102,111,117,114,50,53, >>>>> >>>>> 54,44,97,114,99,102,111,117,114,49,50,56,44,97,101, >>>>> >>>>> 115,49,50,56,45,99,98,99,44,51,100,101,115,45,99,98, >>>>> >>>>> 99,44,98,108,111,119,102,105,115,104,45,99,98,99,44, >>>>> >>>>> 99,97,115,116,49,50,56,45,99,98,99,44,97,101,115,49, >>>>> >>>>> 57,50,45,99,98,99,44,97,101,115,50,53,54,45,99,98, >>>>> >>>>> 99,44,97,114,99,102,111,117,114,44,114,105,106,110, >>>>> >>>>> >> 100,97,101,108,45,99,98,99,64,108,121,115,97,116, >> >>>>> 111,114,46,108,105,117,46,115,101,0,0,0,157,97,101, >>>>> >>>>> 115,49,50,56,45,99,116,114,44,97,101,115,49,57,50, >>>>> >>>>> 45,99,116,114,44,97,101,115,50,53,54,45,99,116,114, >>>>> >>>>> 44,97,114,99,102,111,117,114,50,53,54,44,97,114,99, >>>>> >>>>> 102,111,117,114,49,50,56,44,97,101,115,49,50,56,45, >>>>> >>>>> >> 99,98,99,44,51,100,101,115,45,99,98,99,44,98,108, >> >> 111,119,102,105,115,104,45,99,98,99,44,99,97,115, >> >>>>> 116,49,50,56,45,99,98,99,44,97,101,115,49,57,50,45, >>>>> >>>>> 99,98,99,44,97,101,115,50,53,54,45,99,98,99,44,97, >>>>> >>>>> >> 114,99,102,111,117,114,44,114,105,106,110,100,97, >> >>>>> 101,108,45,99,98,99,64,108,121,115,97,116,111,114, >>>>> >>>>> 46,108,105,117,46,115,101,0,0,0,105,104,109,97,99, >>>>> >>>>> 45,109,100,53,44,104,109,97,99,45,115,104,97,49,44, >>>>> >>>>> 117,109,97,99,45,54,52,64,111,112,101,110,115,115, >>>>> >>>>> 104,46,99,111,109,44,104,109,97,99,45,114,105,112, >>>>> >>>>> >> 101,109,100,49,54,48,44,104,109,97,99,45,114,105, >> >>>>> 112,101,109,100,49,54,48,64,111,112,101,110,115,115, >>>>> >>>>> 104,46,99,111,109,44,104,109,97,99,45,115,104,97,49, >>>>> >>>>> 45,57,54,44,104,109,97,99,45,109,100,53,45,57,54,0, >>>>> >>>>> 0,0,105,104,109,97,99,45,109,100,53,44,104,109,97, >>>>> >>>>> >> 99,45,115,104,97,49,44,117,109,97,99,45,54,52,64, >> >> 111,112,101,110,115,115,104,46,99,111,109,44,104, >> >> 109,97,99,45,114,105,112,101,109,100,49,54,48,44, >> >>>>> 104,109,97,99,45,114,105,112,101,109,100,49,54,48, >>>>> >>>>> 64,111,112,101,110,115,115,104,46,99,111,109,44,104, >>>>> >>>>> 109,97,99,45,115,104,97,49,45,57,54,44,104,109,97, >>>>> >>>>> 99,45,109,100,53,45,57,54,0,0,0,26,110,111,110,101, >>>>> >>>>> 44,122,108,105,98,64,111,112,101,110,115,115,104,46, >>>>> >>>>> 99,111,109,44,122,108,105,98,0,0,0,26,110,111,110, >>>>> >>>>> >> 101,44,122,108,105,98,64,111,112,101,110,115,115, >> >>>>> 104,46,99,111,109,44,122,108,105,98,0,0,0,0,0,0,0,0, >>>>> 0,0,0,0,0>>, >>>>> >>>>> <<20,38,144,242,6,169,190,51,74,102,5,149,16,239,7,65, >>>>> >>>>> 57,0,0,0,26,100,105,102,102,105,101,45,104,101,108, >>>>> >>>>> 108,109,97,110,45,103,114,111,117,112,49,45,115,104, >>>>> >>>>> 97,49,0,0,0,7,115,115,104,45,100,115,115,0,0,0,19, >>>>> >>>>> 97,101,115,49,50,56,45,99,98,99,44,51,100,101,115, >>>>> >>>>> 45,99,98,99,0,0,0,19,97,101,115,49,50,56,45,99,98, >>>>> >>>>> 99,44,51,100,101,115,45,99,98,99,0,0,0,9,104,109,97, >>>>> >>>>> >> 99,45,115,104,97,49,0,0,0,9,104,109,97,99,45,115, >> >>>>> 104,97,49,0,0,0,9,110,111,110,101,44,122,108,105,98, >>>>> >>>>> 0,0,0,9,110,111,110,101,44,122,108,105,98,0,0,0,0,0, >>>>> 0,0,0,0,0,0,0,0>>, >>>>> {alg,'diffie-hellman-group1-sha1','ssh-dss', >>>>> 'hmac-sha1','hmac-sha1','aes128-cbc', >>>>> 'aes128-cbc',none,none,none,none}, >>>>> >>>>> undefined,undefined,ssh_file,ssh_io,none,undefined,0, >>>>> >>>>> >> none,undefined,0,none,undefined,8,undefined,none, >> >>>>> undefined,8,undefined,none,undefined,none,undefined, >>>>> none,none,true,infinity,undefined,undefined, >>>>> undefined, >>>>> [{address,"ims"}, >>>>> {port,2223}, >>>>> {system_dir,"/Users/gene/erl_ssh"}, >>>>> {shell,#Fun}, >>>>> {role,server}], >>>>> 1,1,undefined,undefined,undefined,undefined, >>>>> >>>>> undefined,"publickey,keyboard_interactive,password", >>>>> undefined,undefined}, >>>>> #Port<0.1003>,<<>>,<<>>,undefined, >>>>> {ssh_msg_kexinit, >>>>> >>>>> >> <<127,229,163,177,131,154,163,20,128,32,226,34,154, >> >>>>> 235,187,170>>, >>>>> ["diffie-hellman-group1-sha1"], >>>>> ["ssh-dss"], >>>>> ["aes128-cbc","3des-cbc"], >>>>> ["aes128-cbc","3des-cbc"], >>>>> ["hmac-sha1"], >>>>> ["hmac-sha1"], >>>>> ["none","zlib"], >>>>> ["none","zlib"], >>>>> [],[],false,0}, >>>>> false,<0.54.0>,undefined,undefined,undefined, >>>>> [{address,"ims"}, >>>>> {port,2223}, >>>>> {system_dir,"/Users/gene/erl_ssh"}, >>>>> {shell,#Fun}, >>>>> {role,server}]} >>>>> ** Reason for termination = >>>>> ** >>>>> >>>>> >> {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, >> >>>>> 87,111,15,213,167,162,93,159,122,170,251,197,236, >>>>> >>>>> >> 195,42,174,179,117,37,219,193,70,162,69,63,82, >> >>>>> 132,149,99,206,90,198,153,34,211,176,14,89,142, >>>>> >>>>> 220,203,9,122,34,99,12,156,119,19,117,186,2,233, >>>>> >>>>> 151,22,31,96,153,210,219,121,225,207,231,39,246, >>>>> >>>>> 64,108,176,211,77,252,98,34,16,210,73,17,189,187, >>>>> >>>>> 193,111,191,143,115,49,60,159,218,245,67,241,2, >>>>> >>>>> >> 130,232,145,217,10,236,86,139,125,238,252,102, >> >>>>> 246,213,110,249,125,80,182,210,55,229,163,214,91, >>>>> >>>>> 112,60,117,209,220,205,2,21,0,159,83,129,175,245, >>>>> >>>>> >> 131,186,139,165,18,35,133,43,148,124,202,31,9, >> >>>>> 142,189,2,129,128,107,72,221,121,89,226,22,151, >>>>> >>>>> 35,105,202,173,197,168,100,60,58,6,23,223,9,121, >>>>> >>>>> 175,53,248,135,5,120,183,100,107,135,102,219,116, >>>>> >>>>> 63,213,17,149,118,142,19,143,204,168,236,49,165, >>>>> >>>>> 1,136,195,111,248,199,182,253,234,46,173,28,30, >>>>> >>>>> 114,240,8,77,176,107,184,41,108,183,172,165,202, >>>>> >>>>> >> 3,90,166,69,76,202,187,58,133,192,38,1,38,110, >> >>>>> 212,36,18,35,149,58,218,69,134,143,42,1,174,19, >>>>> >>>>> 233,236,61,165,187,157,254,168,163,243,248,227, >>>>> >>>>> 110,122,213,72,107,214,220,212,99,245,106,120,91, >>>>> >>>>> 131,2,129,128,113,214,224,173,14,157,34,113,59, >>>>> >>>>> 116,57,129,233,210,114,12,213,159,133,106,34,130, >>>>> >>>>> 102,199,157,241,226,84,186,245,237,230,106,6,231, >>>>> >>>>> 231,140,208,106,53,74,56,77,48,92,112,47,91,236, >>>>> >>>>> >> 135,107,16,8,93,241,130,5,118,126,197,127,233, >> >>>>> 238,199,226,7,79,225,193,139,174,87,11,168,190, >>>>> >>>>> 220,127,150,135,210,198,209,242,104,166,143,236, >>>>> >>>>> 18,125,22,64,26,53,139,45,219,45,144,236,245,193, >>>>> >>>>> 127,152,100,103,179,152,156,208,18,94,96,227,44, >>>>> >>>>> 151,136,194,77,114,12,70,223,143,194,196,204,101, >>>>> >>>>> 184,2,20,43,222,65,115,20,238,35,218,102,176,95, >>>>> 196,101,68,47,163,229,153,49,118>>, >>>>> not_encrypted}]} >>>>> >>>>> =ERROR REPORT==== 15-Sep-2010::17:18:48 === >>>>> ** Generic server <0.52.0> terminating >>>>> ** Last message in was {'EXIT',<0.55.0>, >>>>> {error, >>>>> [{'DSAPrivateKey', >>>>> >>>>> <<48,130,1,186,2,1,0,2,129,129,0,170,223, >>>>> >>>>> 146,206,87,111,15,213,167,162,93,159,122, >>>>> >>>>> >> 170,251,197,236,195,42,174,179,117,37, >> >>>>> 219,193,70,162,69,63,82,132,149,99,206, >>>>> >>>>> 90,198,153,34,211,176,14,89,142,220,203, >>>>> >>>>> 9,122,34,99,12,156,119,19,117,186,2,233, >>>>> >>>>> 151,22,31,96,153,210,219,121,225,207,231, >>>>> >>>>> >> 39,246,64,108,176,211,77,252,98,34,16, >> >>>>> 210,73,17,189,187,193,111,191,143,115,49, >>>>> >>>>> 60,159,218,245,67,241,2,130,232,145,217, >>>>> >>>>> >> 10,236,86,139,125,238,252,102,246,213, >> >>>>> 110,249,125,80,182,210,55,229,163,214,91, >>>>> >>>>> 112,60,117,209,220,205,2,21,0,159,83,129, >>>>> >>>>> 175,245,131,186,139,165,18,35,133,43,148, >>>>> >>>>> >> 124,202,31,9,142,189,2,129,128,107,72, >> >>>>> 221,121,89,226,22,151,35,105,202,173,197, >>>>> >>>>> 168,100,60,58,6,23,223,9,121,175,53,248, >>>>> >>>>> 135,5,120,183,100,107,135,102,219,116,63, >>>>> >>>>> 213,17,149,118,142,19,143,204,168,236,49, >>>>> >>>>> 165,1,136,195,111,248,199,182,253,234,46, >>>>> >>>>> >> 173,28,30,114,240,8,77,176,107,184,41, >> >>>>> 108,183,172,165,202,3,90,166,69,76,202, >>>>> >>>>> 187,58,133,192,38,1,38,110,212,36,18,35, >>>>> >>>>> >> 149,58,218,69,134,143,42,1,174,19,233, >> >>>>> 236,61,165,187,157,254,168,163,243,248, >>>>> >>>>> >> 227,110,122,213,72,107,214,220,212,99, >> >>>>> 245,106,120,91,131,2,129,128,113,214,224, >>>>> >>>>> 173,14,157,34,113,59,116,57,129,233,210, >>>>> >>>>> >> 114,12,213,159,133,106,34,130,102,199, >> >>>>> 157,241,226,84,186,245,237,230,106,6,231, >>>>> >>>>> 231,140,208,106,53,74,56,77,48,92,112,47, >>>>> >>>>> 91,236,135,107,16,8,93,241,130,5,118,126, >>>>> >>>>> 197,127,233,238,199,226,7,79,225,193,139, >>>>> >>>>> >> 174,87,11,168,190,220,127,150,135,210, >> >>>>> 198,209,242,104,166,143,236,18,125,22,64, >>>>> >>>>> 26,53,139,45,219,45,144,236,245,193,127, >>>>> >>>>> 152,100,103,179,152,156,208,18,94,96,227, >>>>> >>>>> 44,151,136,194,77,114,12,70,223,143,194, >>>>> >>>>> >> 196,204,101,184,2,20,43,222,65,115,20, >> >>>>> 238,35,218,102,176,95,196,101,68,47,163, >>>>> 229,153,49,118>>, >>>>> not_encrypted}]}} >>>>> ** When Server state == {state,server,<0.54.0>,<0.55.0>,undefined} >>>>> ** Reason for termination == >>>>> ** >>>>> >>>>> >> {error,[{'DSAPrivateKey',<<48,130,1,186,2,1,0,2,129,129,0,170,223,146,206, >> >>>>> 87,111,15,213,167,162,93,159,122,170,251,197,236, >>>>> >>>>> >> 195,42,174,179,117,37,219,193,70,162,69,63,82, >> >>>>> 132,149,99,206,90,198,153,34,211,176,14,89,142, >>>>> >>>>> 220,203,9,122,34,99,12,156,119,19,117,186,2,233, >>>>> >>>>> 151,22,31,96,153,210,219,121,225,207,231,39,246, >>>>> >>>>> 64,108,176,211,77,252,98,34,16,210,73,17,189,187, >>>>> >>>>> 193,111,191,143,115,49,60,159,218,245,67,241,2, >>>>> >>>>> >> 130,232,145,217,10,236,86,139,125,238,252,102, >> >>>>> 246,213,110,249,125,80,182,210,55,229,163,214,91, >>>>> >>>>> 112,60,117,209,220,205,2,21,0,159,83,129,175,245, >>>>> >>>>> >> 131,186,139,165,18,35,133,43,148,124,202,31,9, >> >>>>> 142,189,2,129,128,107,72,221,121,89,226,22,151, >>>>> >>>>> 35,105,202,173,197,168,100,60,58,6,23,223,9,121, >>>>> >>>>> 175,53,248,135,5,120,183,100,107,135,102,219,116, >>>>> >>>>> 63,213,17,149,118,142,19,143,204,168,236,49,165, >>>>> >>>>> 1,136,195,111,248,199,182,253,234,46,173,28,30, >>>>> >>>>> 114,240,8,77,176,107,184,41,108,183,172,165,202, >>>>> >>>>> >> 3,90,166,69,76,202,187,58,133,192,38,1,38,110, >> >>>>> 212,36,18,35,149,58,218,69,134,143,42,1,174,19, >>>>> >>>>> 233,236,61,165,187,157,254,168,163,243,248,227, >>>>> >>>>> 110,122,213,72,107,214,220,212,99,245,106,120,91, >>>>> >>>>> 131,2,129,128,113,214,224,173,14,157,34,113,59, >>>>> >>>>> 116,57,129,233,210,114,12,213,159,133,106,34,130, >>>>> >>>>> 102,199,157,241,226,84,186,245,237,230,106,6,231, >>>>> >>>>> 231,140,208,106,53,74,56,77,48,92,112,47,91,236, >>>>> >>>>> >> 135,107,16,8,93,241,130,5,118,126,197,127,233, >> >>>>> 238,199,226,7,79,225,193,139,174,87,11,168,190, >>>>> >>>>> 220,127,150,135,210,198,209,242,104,166,143,236, >>>>> >>>>> 18,125,22,64,26,53,139,45,219,45,144,236,245,193, >>>>> >>>>> 127,152,100,103,179,152,156,208,18,94,96,227,44, >>>>> >>>>> 151,136,194,77,114,12,70,223,143,194,196,204,101, >>>>> >>>>> 184,2,20,43,222,65,115,20,238,35,218,102,176,95, >>>>> 196,101,68,47,163,229,153,49,118>>, >>>>> not_encrypted}]} >>>>> >>>>> >>>>> ________________________________________________________________ >>>>> erlang-bugs (at) erlang.org mailing list. >>>>> See http://www.erlang.org/faq.html >>>>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >>>>> >>>>> >>>>> >>>> -- >>>> Maxim Treskin >>>> >>>> >>> >>> ________________________________________________________________ >>> erlang-bugs (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >>> >>> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> >> >> > > > From pguyot@REDACTED Mon Sep 27 16:38:51 2010 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 27 Sep 2010 16:38:51 +0200 Subject: HiPE glue: amd64 bug in handle_trap Message-ID: <557798F9-D84C-4BAD-A54B-298465058762@kallisys.net> Hello, I suspect that there is a bug here: http://github.com/erlang/otp/blob/dev/erts/emulator/hipe/hipe_amd64_glue.S#L405 As mentioned on line 390, N_ARITY is a 32 bits value. The instruction line 405 should probably be replaced with: movl %eax, P_NARITY(P) # Note: narity is a 32-bit field Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From larpalarpa@REDACTED Mon Sep 27 17:08:05 2010 From: larpalarpa@REDACTED (Lars) Date: Mon, 27 Sep 2010 17:08:05 +0200 Subject: EUnit and code loading Message-ID: Hi! I have a problem with EUnit and loading code in runtime that I believe to be a bug. Consider these two simple modules a and b that I made to illustrate the problem: Module a: -module(a). -include_lib("eunit/include/eunit.hrl"). a_test() -> load_new_b(), new = b:f(). load_new_b() -> code:purge(b), code:delete(b), {ok, Module, Binary} = compile:forms([{attribute, 1, module, b}, {attribute, 1, export, [{f, 0}]}, {function, 1, f, 0, [{clause, 1, [], [], [{atom, 1, new}]}]}]), {module, b} = erlang:load_module(b, Binary). Module b: -module(b). -include_lib("eunit/include/eunit.hrl"). -export([f/0]). f() -> old. load_new_b replaces the b module and changes the definition of b:f to return the atom new instead of old, so a_test should pass. To reproduce the problem: * Compile a.erl and b.erl and start a shell * Run eunit:test("a.beam"). * Run eunit:test("b.beam"). * Run eunit:test("a.beam"). The output will be on the form: 1> eunit:test("a.beam"). Test passed. ok 2> eunit:test("b.beam"). There were no tests to run. ok 3> eunit:test("a.beam"). a: a_test (module 'a')...*failed* ::error:{badmatch,old} in function a:a_test/0 in call from eunit:test/1 However, if instead of the "a.beam" syntax the modules are named as terms (eunit:test(a)), the above works. Both eunit:test({inorder, [b, a]}) and eunit:test({inorder, ["b.beam", "a.beam"]}) fail. So the problem is that I can't replace a module that has been previously tested by EUnit. For some reason it works when using the module term syntax, though. Verified on Mac OS X 10.6.4, Erlang version: R14B. Probably Linux also, although this exact program was not tested there. Does not seem to occur in Windows. / Lars From mpollack@REDACTED Mon Sep 27 17:33:09 2010 From: mpollack@REDACTED (Mark Pollack) Date: Mon, 27 Sep 2010 08:33:09 -0700 Subject: jinterface hides root exception on connect Message-ID: <806F700D7E08E9408413160B05EB66672A48CE45D3@EXCH-MBX-1.vmware.com> Hi, The following catch statement in jinterface's AbstractConnection.doConnect method } catch (final Exception e) { close(); throw new IOException("Cannot connect to peer node"); } Is hiding some good information making it difficult for users of my library (which uses jinterface) to diagnose connection errors. Can you please propagate the underlying root exception when throwing the IOException. I am using jinterface 1.5.3 as it is available in the public maven repository. Thanks, Mark From mikpe@REDACTED Mon Sep 27 18:26:10 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Mon, 27 Sep 2010 18:26:10 +0200 Subject: HiPE glue: amd64 bug in handle_trap In-Reply-To: <557798F9-D84C-4BAD-A54B-298465058762@kallisys.net> References: <557798F9-D84C-4BAD-A54B-298465058762@kallisys.net> Message-ID: <19616.50594.922960.87700@pilspetsen.it.uu.se> Paul Guyot writes: > Hello, > > I suspect that there is a bug here: > http://github.com/erlang/otp/blob/dev/erts/emulator/hipe/hipe_amd64_glue.S#L405 > > As mentioned on line 390, N_ARITY is a 32 bits value. The instruction line 405 should probably be replaced with: > > movl %eax, P_NARITY(P) # Note: narity is a 32-bit field Thanks. Yes it's a bug, and there's a similar one in hipe_ppc_glue.S. I'll send a patch in a few minutes. /Mikael From pguyot@REDACTED Mon Sep 27 18:30:59 2010 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 27 Sep 2010 18:30:59 +0200 Subject: Bugs with hibernate/3 and HiPE Message-ID: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> Hello, There are several bugs related to hibernate/3 BIF and HiPE: 1. erlang:hibernate/3 simply fails with badarg when called from HiPE. 2. erlang:hibernate/3 simply fails with badarg when called dynamically, in a way that the compiler and the loader cannot replace with the i_hibernate beam instruction. 3. There is a segfault in the garbage collector when calling erlang:hibernate/3 (from beam unless bug #1 is fixed) if the process went through HiPE. This is because erts_garbage_collect_hibernate would not clean up the hipe process state. These bugs are highly related: 1 and 2 are actually the same bug (hibernate/3 BIF isn't implemented, and apparently wasn't since it was introduced), and 3 causes segfaults with any reasonable test once bug #1 is fixed. The following patch fixes these issues: http://github.com/pguyot/otp/commit/fcc005c8758d97d7f0c402bfffede0b22b8ab401 git fetch git://github.com/pguyot/otp.git fix-hibernate-with-hipe Regards, Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From kruber@REDACTED Tue Sep 28 11:24:22 2010 From: kruber@REDACTED (Nico Kruber) Date: Tue, 28 Sep 2010 11:24:22 +0200 Subject: [erlang-bugs] illegal declaration of pertially defined record types in dialyzer, R14A In-Reply-To: <201009131037.01152.vincent.dephily@mobile-devices.fr> References: <201008311526.18180.kruber@zib.de> <201008311603.43854.kruber@zib.de> <201009131037.01152.vincent.dephily@mobile-devices.fr> Message-ID: <201009281124.28257.kruber@zib.de> On Monday 13 September 2010 10:37:01 Vincent de Phily wrote: > On Tuesday 31 August 2010 16:03:38 Nico Kruber wrote: > > The type I use now is defined opaque but every method in the according > > module gets well-formed records, i.e. no 'undefined' fields. I cannot > > provide useful initialisers though because we store pids, for example. > > We not have to distinguish well-formed records and those that may be > > partially undefined and the given declaration would solve this problem. > > What I do in those cases is to set a throw()n value as the default value. > It's not 100% satisfying but it solves a few problems : > > > -define(required(Record, Field), throw({record_field_required, Record, > Field, ?MODULE})). > > -record(file, {size = ?required(file, size) :: integer()}). thanks, this helped a lot to work around that bug (and also saves some code- duplication) Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From pguyot@REDACTED Tue Sep 28 11:40:05 2010 From: pguyot@REDACTED (Paul Guyot) Date: Tue, 28 Sep 2010 11:40:05 +0200 Subject: process_info(P,current_function) and HiPE (was Re: Bugs with hibernate/3 and HiPE) In-Reply-To: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> Message-ID: <94679BA9-92D1-4A8E-938D-E401C918C570@kallisys.net> > Hello, > > There are several bugs related to hibernate/3 BIF and HiPE: > > 1. erlang:hibernate/3 simply fails with badarg when called from HiPE. > 2. erlang:hibernate/3 simply fails with badarg when called dynamically, in a way that the compiler and the loader cannot replace with the i_hibernate beam instruction. > 3. There is a segfault in the garbage collector when calling erlang:hibernate/3 (from beam unless bug #1 is fixed) if the process went through HiPE. This is because erts_garbage_collect_hibernate would not clean up the hipe process state. > > These bugs are highly related: 1 and 2 are actually the same bug (hibernate/3 BIF isn't implemented, and apparently wasn't since it was introduced), and 3 causes segfaults with any reasonable test once bug #1 is fixed. > > The following patch fixes these issues: > http://github.com/pguyot/otp/commit/fcc005c8758d97d7f0c402bfffede0b22b8ab401 > git fetch git://github.com/pguyot/otp.git fix-hibernate-with-hipe Hello, I realize I sent the e-mail above to erlang-bugs@ instead of erlang-patches@REDACTED Besides, even with this fix to hibernate, gen_server_SUITE:hibernate/1 test does not pass when OTP is configured with --enable-native-libs. This is not because the process does not hibernate or does not wake up. Instead, the test heavily relies on process_info(P, current_function) which is not updated by HiPE, while beam updates it (on context switch, I guess). What is the policy for current_function? When started and when awoken after an hibernation, a simple gen_server with a non-native callback module with non-native gen_server and non-native proc_lib modules reports {current_function,{gen_server,loop,6}}. The same non-native callback module with native proc_lib and native gen_server reports {current_function,undefined} when started and {current_function,{erlang,hibernate,3}} when awoken after an hibernation (because erts_hibernate function sets current to the hibernate_3 BIF). Should we update HiPE to report some current_function, at least when switching mode? Or should we clear the current_function when waking up from hibernation? Regards, Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From mikpe@REDACTED Tue Sep 28 15:20:13 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 28 Sep 2010 15:20:13 +0200 Subject: [erlang-bugs] Bugs with hibernate/3 and HiPE In-Reply-To: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> Message-ID: <19617.60301.343253.697174@pilspetsen.it.uu.se> Paul Guyot writes: > Hello, > > There are several bugs related to hibernate/3 BIF and HiPE: > > 1. erlang:hibernate/3 simply fails with badarg when called from HiPE. > 2. erlang:hibernate/3 simply fails with badarg when called dynamically, in a way that the compiler and the loader cannot replace with the i_hibernate beam instruction. > 3. There is a segfault in the garbage collector when calling erlang:hibernate/3 (from beam unless bug #1 is fixed) if the process went through HiPE. This is because erts_garbage_collect_hibernate would not clean up the hipe process state. > > These bugs are highly related: 1 and 2 are actually the same bug (hibernate/3 BIF isn't implemented, and apparently wasn't since it was introduced), and 3 causes segfaults with any reasonable test once bug #1 is fixed. #1 and #2 are not HiPE bugs but BEAM bugs. Especially the fact that erlang:hibernate/3 can be called in ways that the BEAM compiler/loader combo doesn't recognize and turn into the i_hibernate BEAM instruction. #3 is a HiPE bug, in that HiPE never added support for hibernation, (it's not that we added the support in a broken form). > The following patch fixes these issues: > http://github.com/pguyot/otp/commit/fcc005c8758d97d7f0c402bfffede0b22b8ab401 > git fetch git://github.com/pguyot/otp.git fix-hibernate-with-hipe At a high level I think this is a step in the right direction. The commit has some issues which I can only comment on abstractly since you didn't inline it here. a. Testing a flag in a-bif-just-trapped situations is expedient but extremely ugly. BEAM has the i_hibernate instruction. Either the trap should target a BEAM stub which executes i_hibernate, or i_hibernate should be eliminated altogether in favour of the flag test(s). There should be only one way to hibernate. b. Drop the redundant braces in if (cond) { goto blah; } c. In the hibernate_3 BIF you're declaring an unused `result' variable. Also you're breaking up the local variables with a multi-line comment in the middle: they should all follow the comment, or the comment should be moved above the function head. d. In the hibernate_3 BIF you're assigning to BIF_P->def_arg_reg[3] but I don't see anything in the patch that would use it. Is it redundant? /Mikael From mikpe@REDACTED Tue Sep 28 15:27:53 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 28 Sep 2010 15:27:53 +0200 Subject: process_info(P,current_function) and HiPE (was Re: Bugs with hibernate/3 and HiPE) In-Reply-To: <94679BA9-92D1-4A8E-938D-E401C918C570@kallisys.net> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> <94679BA9-92D1-4A8E-938D-E401C918C570@kallisys.net> Message-ID: <19617.60761.599137.961032@pilspetsen.it.uu.se> Paul Guyot writes: > > Hello, > > > > There are several bugs related to hibernate/3 BIF and HiPE: > > > > 1. erlang:hibernate/3 simply fails with badarg when called from HiPE. > > 2. erlang:hibernate/3 simply fails with badarg when called dynamically, in a way that the compiler and the loader cannot replace with the i_hibernate beam instruction. > > 3. There is a segfault in the garbage collector when calling erlang:hibernate/3 (from beam unless bug #1 is fixed) if the process went through HiPE. This is because erts_garbage_collect_hibernate would not clean up the hipe process state. > > > > These bugs are highly related: 1 and 2 are actually the same bug (hibernate/3 BIF isn't implemented, and apparently wasn't since it was introduced), and 3 causes segfaults with any reasonable test once bug #1 is fixed. > > > > The following patch fixes these issues: > > http://github.com/pguyot/otp/commit/fcc005c8758d97d7f0c402bfffede0b22b8ab401 > > git fetch git://github.com/pguyot/otp.git fix-hibernate-with-hipe > > > Hello, > > I realize I sent the e-mail above to erlang-bugs@ instead of erlang-patches@REDACTED > > Besides, even with this fix to hibernate, gen_server_SUITE:hibernate/1 test does not pass when OTP is configured with --enable-native-libs. This is not because the process does not hibernate or does not wake up. Instead, the test heavily relies on process_info(P, current_function) which is not updated by HiPE, while beam updates it (on context switch, I guess). > > What is the policy for current_function? As far as HiPE is concerned, process_info(P, current_function) is a BEAM-only introspection mechanism that should not be considered part of the Erlang language. It's unfortunate that the test case relies on it. > When started and when awoken after an hibernation, a simple gen_server with a non-native callback module with non-native gen_server and non-native proc_lib modules reports {current_function,{gen_server,loop,6}}. The same non-native callback module with native proc_lib and native gen_server reports {current_function,undefined} when started and {current_function,{erlang,hibernate,3}} when awoken after an hibernation (because erts_hibernate function sets current to the hibernate_3 BIF). Should we update HiPE to report some current_function, at least when switching mode? Or should we clear the current_function when waking up from hibernation? Please investigate: a) when and how BEAM updates current_function, and b) when you're allowed to call process_info(P, current_function) on a BEAM-mode function and what it returns; what if the target process is currently running? does it stop or does process_info then return stale data c) to what extent the hibernate test relies on the above Then maybe we can find a way to emulate the needed functionality without hurting performance. /Mikael From mikpe@REDACTED Tue Sep 28 15:53:42 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 28 Sep 2010 15:53:42 +0200 Subject: [erlang-bugs] Bugs with hibernate/3 and HiPE In-Reply-To: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> Message-ID: <19617.62310.999688.690826@pilspetsen.it.uu.se> Paul Guyot writes: > Hello, > > There are several bugs related to hibernate/3 BIF and HiPE: > > 1. erlang:hibernate/3 simply fails with badarg when called from HiPE. > 2. erlang:hibernate/3 simply fails with badarg when called dynamically, in a way that the compiler and the loader cannot replace with the i_hibernate beam instruction. > 3. There is a segfault in the garbage collector when calling erlang:hibernate/3 (from beam unless bug #1 is fixed) if the process went through HiPE. This is because erts_garbage_collect_hibernate would not clean up the hipe process state. > > These bugs are highly related: 1 and 2 are actually the same bug (hibernate/3 BIF isn't implemented, and apparently wasn't since it was introduced), and 3 causes segfaults with any reasonable test once bug #1 is fixed. > > The following patch fixes these issues: > http://github.com/pguyot/otp/commit/fcc005c8758d97d7f0c402bfffede0b22b8ab401 > git fetch git://github.com/pguyot/otp.git fix-hibernate-with-hipe Your "fix" for #3 is wrong I think. hibernate should empty the stack. If you don't empty the native stack then yes, at the next GC, we'd scan a dead stack, find dead pointers to stale data, and do bad things. Your call to fullsweep_nstack() changes this so that in the next GC we scan a dead stack, find dead pointers to tenured data, and don't crash. The correct fix ought to be to simply empty the native stack. There's no existing procedure for doing that, but something like void hipe_empty_nstack(Process *p) { p->hipe.nstgraylim = NULL; #if defined(HIPE_NSTACK_GROWS_DOWN) p->hipe.nsp = p->hipe.nstend; #else p->hipe.nsp = p->hipe.nstack; #endif } should be close to what's needed. hipe_native_bifs.c right after the definitions of hipe_inc_nstack() seems like a reasonable place to put it. /Mikael From pguyot@REDACTED Tue Sep 28 15:58:34 2010 From: pguyot@REDACTED (Paul Guyot) Date: Tue, 28 Sep 2010 15:58:34 +0200 Subject: [erlang-bugs] Bugs with hibernate/3 and HiPE In-Reply-To: <19617.60301.343253.697174@pilspetsen.it.uu.se> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> <19617.60301.343253.697174@pilspetsen.it.uu.se> Message-ID: <1847F1BA-1E92-4DCC-BDF7-52B6ABE34C4A@kallisys.net> Mikael, Thank you for your e-mail. >> There are several bugs related to hibernate/3 BIF and HiPE: >> >> 1. erlang:hibernate/3 simply fails with badarg when called from HiPE. >> 2. erlang:hibernate/3 simply fails with badarg when called dynamically, in a way that the compiler and the loader cannot replace with the i_hibernate beam instruction. >> 3. There is a segfault in the garbage collector when calling erlang:hibernate/3 (from beam unless bug #1 is fixed) if the process went through HiPE. This is because erts_garbage_collect_hibernate would not clean up the hipe process state. >> >> These bugs are highly related: 1 and 2 are actually the same bug (hibernate/3 BIF isn't implemented, and apparently wasn't since it was introduced), and 3 causes segfaults with any reasonable test once bug #1 is fixed. > > #1 and #2 are not HiPE bugs but BEAM bugs. Especially the fact that > erlang:hibernate/3 can be called in ways that the BEAM compiler/loader > combo doesn't recognize and turn into the i_hibernate BEAM instruction. > #3 is a HiPE bug, in that HiPE never added support for hibernation, > (it's not that we added the support in a broken form). Who's bug it is does not really matter. From a user perspective, in R14B and earlier, erlang:hibernate/3 would not work when called from a native module and can crash in complex scenarios if the process previously went through some native code. > a. Testing a flag in a-bif-just-trapped situations is expedient but > extremely ugly. BEAM has the i_hibernate instruction. Either the > trap should target a BEAM stub which executes i_hibernate, or i_hibernate > should be eliminated altogether in favour of the flag test(s). There > should be only one way to hibernate. While I agree that there should be only one way to hibernate (hence the erts_hibernate function), I chose not to TRAP to a new BEAM stub and test against the status flag for two reasons: - the proposed solution involves the smallest change - going to do_schedule instead of immediatly calling the TRAP function (HiPE) or doing DoDispatch (BEAM) when status flag is P_WAITING (in other words, if the process should be rescheduled) doesn't break any semantics at all, works for hibernating and could be extended for other yield cases (I think TRAP is used in some BIFs to give CPU time to other processes). > b. Drop the redundant braces in > if (cond) { > goto blah; > } Is there a reference or commonly approved style guidelines for OTP source code? The braces match what can be found in beam_emu.c. > c. In the hibernate_3 BIF you're declaring an unused `result' variable. Well spotted! > d. In the hibernate_3 BIF you're assigning to BIF_P->def_arg_reg[3] but > I don't see anything in the patch that would use it. Is it redundant? It is used in BEAM TRAP handler: http://github.com/erlang/otp/blob/dev/erts/emulator/beam/beam_emu.c#L3200 Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From pguyot@REDACTED Tue Sep 28 16:21:47 2010 From: pguyot@REDACTED (Paul Guyot) Date: Tue, 28 Sep 2010 16:21:47 +0200 Subject: [erlang-bugs] Bugs with hibernate/3 and HiPE In-Reply-To: <19617.62310.999688.690826@pilspetsen.it.uu.se> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> <19617.62310.999688.690826@pilspetsen.it.uu.se> Message-ID: <5E789996-F79E-48C8-8B04-EE4C4C91BCDC@kallisys.net> Le 28 sept. 2010 ? 15:53, Mikael Pettersson a ?crit : > Your "fix" for #3 is wrong I think. hibernate should empty the stack. > If you don't empty the native stack then yes, at the next GC, we'd > scan a dead stack, find dead pointers to stale data, and do bad things. > Your call to fullsweep_nstack() changes this so that in the next GC > we scan a dead stack, find dead pointers to tenured data, and don't > crash. > > The correct fix ought to be to simply empty the native stack. There's > no existing procedure for doing that, but something like > > void hipe_empty_nstack(Process *p) > { > p->hipe.nstgraylim = NULL; > #if defined(HIPE_NSTACK_GROWS_DOWN) > p->hipe.nsp = p->hipe.nstend; > #else > p->hipe.nsp = p->hipe.nstack; > #endif > } > > should be close to what's needed. hipe_native_bifs.c right after the > definitions of hipe_inc_nstack() seems like a reasonable place to put it. Mikael, Thank you for your e-mail and carefully reviewing this fix. I initially tried to empty the native stack but this crashed, as I definitely lacked the grasp of the native garbage collector for this fix. This function seems to work, at least the hibernate_native_SUITE tests pass. I committed your suggested change on top of the original commit here: git fetch git://github.com/pguyot/otp.git fix-hibernate-with-hipe http://github.com/pguyot/otp/commit/1d5234d5ef54f60e50b36d42083a8cd86429bcb4 Also, I guess you meant hipe_switch_mode.c instead of hipe_native_bifs.c. Regards, Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From pguyot@REDACTED Tue Sep 28 17:52:00 2010 From: pguyot@REDACTED (Paul Guyot) Date: Tue, 28 Sep 2010 17:52:00 +0200 Subject: process_info(P,current_function) and HiPE (was Re: Bugs with hibernate/3 and HiPE) In-Reply-To: <19617.60761.599137.961032@pilspetsen.it.uu.se> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> <94679BA9-92D1-4A8E-938D-E401C918C570@kallisys.net> <19617.60761.599137.961032@pilspetsen.it.uu.se> Message-ID: <6C940E94-C9AD-4441-84DE-B34201F6A791@kallisys.net> Mikael, Thank you for your e-mail. > Please investigate: > a) when and how BEAM updates current_function, and c_p->current is either set to NULL or to a pointer to an {M,F,A} instruction triplet. It is set: - on context switch (which are always when entering a function) - when calling a NIF - on apply_bif - on hibernate - on various exception handlers and signaling. > b) when you're allowed to call process_info(P, current_function) on > a BEAM-mode function and what it returns; what if the target process > is currently running? does it stop or does process_info then return > stale data I guess process_info returns stale data (simply the value of process->current). > c) to what extent the hibernate test relies on the above It is only used to figure out if the process is or is not hibernating. Indepently from the test, what I am mostly concerned with is that erts_hibernate sets current to {erlang,hibernate,3} and when the process wakes up, we should set it to a proper value (either the function being executed or NULL). If the wake up function is native, this does not happen and it remains {erlang,hibernate,3}. The gen_server_SUITE:hibernate/1 test passes when simply setting c_p->current to I-3 in beam_emu.c's OpCase(hipe_trap_call), i.e. defining current to be the called native function. However, this looks weird because the data is definitely incorrect when the process is later switched out, waiting for a message. So I suggest to also clear current when exiting hipe_mode_switch in wait or suspend states. This is the content of the patch below. If you're fine with it, I'll submit it to erlang-patches@REDACTED Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris diff --git a/erts/emulator/beam/beam_emu.c b/erts/emulator/beam/beam_emu.c index 8a0e12d..ce49299 100644 --- a/erts/emulator/beam/beam_emu.c +++ b/erts/emulator/beam/beam_emu.c @@ -4850,6 +4850,7 @@ apply_bif_or_nif_epilogue: * ... remainder of original BEAM code */ ASSERT(I[-5] == (Uint) OpCode(i_func_info_IaaI)); + c_p->current = I-3; c_p->hipe.ncallee = (void(*)(void)) I[-4]; cmd = HIPE_MODE_SWITCH_CMD_CALL | (I[-1] << 8); ++hipe_trap_count; diff --git a/erts/emulator/hipe/hipe_mode_switch.c b/erts/emulator/hipe/hipe_mode_switch.c index e5de244..181f9c8 100644 --- a/erts/emulator/hipe/hipe_mode_switch.c +++ b/erts/emulator/hipe/hipe_mode_switch.c @@ -425,6 +425,7 @@ Process *hipe_mode_switch(Process *p, unsigned cmd, Eterm reg[]) case HIPE_MODE_SWITCH_RES_SUSPEND: { p->i = hipe_beam_pc_resume; p->arity = 0; + p->current = NULL; erts_smp_proc_lock(p, ERTS_PROC_LOCK_STATUS); if (p->status != P_SUSPENDED) erts_add_to_runq(p); @@ -445,6 +446,7 @@ Process *hipe_mode_switch(Process *p, unsigned cmd, Eterm reg[]) p->i = hipe_beam_pc_resume; p->arity = 0; p->status = P_WAITING; + p->current = NULL; erts_smp_proc_unlock(p, ERTS_PROC_LOCKS_MSG_RECEIVE); do_schedule: { From mikpe@REDACTED Wed Sep 29 13:43:09 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 29 Sep 2010 13:43:09 +0200 Subject: process_info(P,current_function) and HiPE (was Re: Bugs with hibernate/3 and HiPE) In-Reply-To: <6C940E94-C9AD-4441-84DE-B34201F6A791@kallisys.net> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> <94679BA9-92D1-4A8E-938D-E401C918C570@kallisys.net> <19617.60761.599137.961032@pilspetsen.it.uu.se> <6C940E94-C9AD-4441-84DE-B34201F6A791@kallisys.net> Message-ID: <19619.9805.31482.502922@pilspetsen.it.uu.se> Paul Guyot writes: > Mikael, > > Thank you for your e-mail. > > > Please investigate: > > a) when and how BEAM updates current_function, and > > c_p->current is either set to NULL or to a pointer to an {M,F,A} instruction triplet. > > It is set: > - on context switch (which are always when entering a function) > - when calling a NIF > - on apply_bif > - on hibernate > - on various exception handlers and signaling. > > > b) when you're allowed to call process_info(P, current_function) on > > a BEAM-mode function and what it returns; what if the target process > > is currently running? does it stop or does process_info then return > > stale data > > I guess process_info returns stale data (simply the value of process->current). > > > c) to what extent the hibernate test relies on the above > > It is only used to figure out if the process is or is not hibernating. Indepently from the test, what I am mostly concerned with is that erts_hibernate sets current to {erlang,hibernate,3} and when the process wakes up, we should set it to a proper value (either the function being executed or NULL). If the wake up function is native, this does not happen and it remains {erlang,hibernate,3}. > > The gen_server_SUITE:hibernate/1 test passes when simply setting c_p->current to I-3 in beam_emu.c's OpCase(hipe_trap_call), i.e. defining current to be the called native function. However, this looks weird because the data is definitely incorrect when the process is later switched out, waiting for a message. So I suggest to also clear current when exiting hipe_mode_switch in wait or suspend states. This is the content of the patch below. If you're fine with it, I'll submit it to erlang-patches@REDACTED > > Paul > -- > Semiocast http://semiocast.com/ > +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris > > diff --git a/erts/emulator/beam/beam_emu.c b/erts/emulator/beam/beam_emu.c > index 8a0e12d..ce49299 100644 > --- a/erts/emulator/beam/beam_emu.c > +++ b/erts/emulator/beam/beam_emu.c > @@ -4850,6 +4850,7 @@ apply_bif_or_nif_epilogue: > * ... remainder of original BEAM code > */ > ASSERT(I[-5] == (Uint) OpCode(i_func_info_IaaI)); > + c_p->current = I-3; > c_p->hipe.ncallee = (void(*)(void)) I[-4]; > cmd = HIPE_MODE_SWITCH_CMD_CALL | (I[-1] << 8); > ++hipe_trap_count; > diff --git a/erts/emulator/hipe/hipe_mode_switch.c b/erts/emulator/hipe/hipe_mode_switch.c > index e5de244..181f9c8 100644 > --- a/erts/emulator/hipe/hipe_mode_switch.c > +++ b/erts/emulator/hipe/hipe_mode_switch.c > @@ -425,6 +425,7 @@ Process *hipe_mode_switch(Process *p, unsigned cmd, Eterm reg[]) > case HIPE_MODE_SWITCH_RES_SUSPEND: { > p->i = hipe_beam_pc_resume; > p->arity = 0; > + p->current = NULL; > erts_smp_proc_lock(p, ERTS_PROC_LOCK_STATUS); > if (p->status != P_SUSPENDED) > erts_add_to_runq(p); > @@ -445,6 +446,7 @@ Process *hipe_mode_switch(Process *p, unsigned cmd, Eterm reg[]) > p->i = hipe_beam_pc_resume; > p->arity = 0; > p->status = P_WAITING; > + p->current = NULL; > erts_smp_proc_unlock(p, ERTS_PROC_LOCKS_MSG_RECEIVE); > do_schedule: > { > I don't like this, it's adding what I believe are redundant assignments in hot paths. The essential problem is that BEAM's hibernate test expects ->current to change soon after wakeup from hibernation. There is no special event for this, only a plain apply of an MFA. In the bug case, that MFA is native and nothing in that path sets ->current. If you look at the start of hipe_mode_switch() you see an assignment of NULL to p->i. Just add "p->current = NULL;" at the same place, with a comment that BEAM's hibernation test relies on it, and drop these other 3 assignments to ->current. That should be enough. /Mikael From pguyot@REDACTED Thu Sep 30 10:28:49 2010 From: pguyot@REDACTED (Paul Guyot) Date: Thu, 30 Sep 2010 10:28:49 +0200 Subject: hibernate/3 and HiPE In-Reply-To: <19619.9805.31482.502922@pilspetsen.it.uu.se> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> <94679BA9-92D1-4A8E-938D-E401C918C570@kallisys.net> <19617.60761.599137.961032@pilspetsen.it.uu.se> <6C940E94-C9AD-4441-84DE-B34201F6A791@kallisys.net> <19619.9805.31482.502922@pilspetsen.it.uu.se> Message-ID: <11B31815-6B3D-44C4-819B-7E9764406984@kallisys.net> Hello, The following branch contains fixes for hibernate/3 and HiPE: http://github.com/pguyot/otp/commits/fix-hibernate-with-hipe git fetch git://github.com/pguyot/otp.git fix-hibernate-with-hipe All the changes have been squashed into a single refined patch: http://github.com/pguyot/otp/commit/19934190bf8c4f1232aefd92bc581b58a8e38d75 This new version of the patch fixes some logic fault in stack emptying and when scheduling after a TRAP in HiPE. It also resets p->current when entering hipe_mode_switch as suggested by Mikael Pettersson, thus making all stdlib hibernate-related tests pass with --enable-native-libs. Regards, Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From bgustavsson@REDACTED Thu Sep 30 14:14:52 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 30 Sep 2010 14:14:52 +0200 Subject: [erlang-patches] Re: process_info(P,current_function) and HiPE (was Re: Bugs with hibernate/3 and HiPE) In-Reply-To: <19617.60761.599137.961032@pilspetsen.it.uu.se> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> <94679BA9-92D1-4A8E-938D-E401C918C570@kallisys.net> <19617.60761.599137.961032@pilspetsen.it.uu.se> Message-ID: On Tue, Sep 28, 2010 at 3:27 PM, Mikael Pettersson wrote: > b) when you're allowed to call process_info(P, current_function) on > a BEAM-mode function and what it returns; what if the target process > is currently running? does it stop or does process_info then return > stale data process_info(P, current_function) will not return stale data. It will wait (in an efficient way) for the target process to stop running before it reads out the current function. So the current function returned will always be the function that was current the last time the target process was scheduled out. Basically, current_function must be up-to-date when scheduling out the process or when process_info(self(), current_function) is called. BEAM calls process_info/{1,2} through apply_bif to make sure that c_p->current_function is up-to-date. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Thu Sep 30 14:55:46 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 30 Sep 2010 14:55:46 +0200 Subject: [erlang-bugs] Bugs with hibernate/3 and HiPE In-Reply-To: <1847F1BA-1E92-4DCC-BDF7-52B6ABE34C4A@kallisys.net> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> <19617.60301.343253.697174@pilspetsen.it.uu.se> <1847F1BA-1E92-4DCC-BDF7-52B6ABE34C4A@kallisys.net> Message-ID: On Tue, Sep 28, 2010 at 3:58 PM, Paul Guyot wrote: >> b. Drop the redundant braces in >> if (cond) { >> goto blah; >> } > > Is there a reference or commonly approved style guidelines for OTP source code? The braces match what can be found in beam_emu.c. No, we don't have any written guidelines. You should match the style of the surrounding code in the same source code file. (That is, if the code is in one of the files in the hipe subdirectory you should drop the braces.) -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Thu Sep 30 14:56:38 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 30 Sep 2010 14:56:38 +0200 Subject: [erlang-patches] Re: [erlang-bugs] Bugs with hibernate/3 and HiPE In-Reply-To: <5E789996-F79E-48C8-8B04-EE4C4C91BCDC@kallisys.net> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> <19617.62310.999688.690826@pilspetsen.it.uu.se> <5E789996-F79E-48C8-8B04-EE4C4C91BCDC@kallisys.net> Message-ID: On Tue, Sep 28, 2010 at 4:21 PM, Paul Guyot wrote: > > git fetch git://github.com/pguyot/otp.git fix-hibernate-with-hipe > http://github.com/pguyot/otp/commit/1d5234d5ef54f60e50b36d42083a8cd86429bcb4 Thanks! Will include in pu. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From mikpe@REDACTED Thu Sep 30 20:57:05 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 30 Sep 2010 20:57:05 +0200 Subject: hibernate/3 and HiPE In-Reply-To: <11B31815-6B3D-44C4-819B-7E9764406984@kallisys.net> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> <94679BA9-92D1-4A8E-938D-E401C918C570@kallisys.net> <19617.60761.599137.961032@pilspetsen.it.uu.se> <6C940E94-C9AD-4441-84DE-B34201F6A791@kallisys.net> <19619.9805.31482.502922@pilspetsen.it.uu.se> <11B31815-6B3D-44C4-819B-7E9764406984@kallisys.net> Message-ID: <19620.56705.858868.664710@pilspetsen.it.uu.se> Paul Guyot writes: > Hello, > > The following branch contains fixes for hibernate/3 and HiPE: > http://github.com/pguyot/otp/commits/fix-hibernate-with-hipe > git fetch git://github.com/pguyot/otp.git fix-hibernate-with-hipe > > All the changes have been squashed into a single refined patch: > http://github.com/pguyot/otp/commit/19934190bf8c4f1232aefd92bc581b58a8e38d75 > > This new version of the patch fixes some logic fault in stack emptying and when scheduling after a TRAP in HiPE. It also resets p->current when entering hipe_mode_switch as suggested by Mikael Pettersson, thus making all stdlib hibernate-related tests pass with --enable-native-libs. This one is Ok.