From matthias@REDACTED Thu Aug 2 00:35:32 2012 From: matthias@REDACTED (Matthias Radestock) Date: Wed, 01 Aug 2012 23:35:32 +0100 Subject: [erlang-bugs] missing function clause in ssl_connection:handle_alert Message-ID: <5019AF34.1060103@rabbitmq.com> We got the following process crash report from a user running R15B01 (trimmed somewhat to hide private key material): =CRASH REPORT==== 31-Jul-2012::11:49:27 === crasher: initial call: ssl_connection:init/1 pid: <0.2005.0> registered_name: [] exception exit: {function_clause, [{ssl_connection,handle_alert, [{alert,1,41,{"ssl_connection.erl",1678}}, certify, {state,server, {#Ref<0.0.0.3519>,<0.2004.0>}, gen_tcp,tcp,tcp_closed,tcp_error,"localhost",5673, #Port<0.6927>, {ssl_options,[],verify_peer, {#Fun, #Fun}, false,false,undefined,1, "C:/certstore/server/cert.pem",undefined, "C:/certstore/server/key.pem",undefined,undefined, undefined,"C:/certstore/testca/cacert.pem", undefined,undefined, [<<0,57>>, <<0,56>>, <<0,53>>, <<0,22>>, <<0,19>>, <<0,10>>, <<0,51>>, <<0,50>>, <<0,47>>, <<0,5>>, <<0,4>>, <<0,21>>, <<0,9>>], #Fun,true,268435456,false,[], undefined,false}, {socket_options,binary,0,0,0,false}, {connection_states, ...}, [],<<>>,<<>>, {...}, [...], 262221, {session, ...}, 274512,ssl_session_cache, {3,0}, undefined,true,rsa,undefined, {'RSAPrivateKey','two-prime', ...}, {'DHParameter', ...}, undefined,undefined,#Ref<0.0.0.3523>, {<0.2004.0>,#Ref<0.0.0.3539>}, 0,<<>>,true, {false,first}, undefined, {[],[]}, false,true}], [{file,"ssl_connection.erl"},{line,2179}]}, {ssl_connection,handle_alerts,2, [{file,"ssl_connection.erl"},{line,2177}]}, {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,494}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,227}]}]} in function gen_fsm:terminate/7 (gen_fsm.erl, line 611) ancestors: [ssl_connection_sup,ssl_sup,<0.225.0>] messages: [] links: [<0.228.0>] dictionary: [{ssl_manager,ssl_manager}] trap_exit: false status: running heap_size: 2584 stack_size: 24 reductions: 2959 neighbours: Sure enough there's no handle_alert function clause that matches on an #alert.description=41. Indeed that alert code isn't even mentioned at ssl_alert.hrl or the rfc 2246 on which that list is supposedly based. It is however shown in rfc 5246 as 'no_certificate_RESERVED', and, as evidenced above, clearly can pop out of the ssl libraries under some circumstances. Regards, Matthias. From essen@REDACTED Thu Aug 2 00:39:11 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 02 Aug 2012 00:39:11 +0200 Subject: [erlang-bugs] missing function clause in ssl_connection:handle_alert In-Reply-To: <5019AF34.1060103@rabbitmq.com> References: <5019AF34.1060103@rabbitmq.com> Message-ID: <5019B00F.4080509@ninenines.eu> I also observed this but with the following difference: [{ssl_connection,handle_alert, [{alert,211,61,{"ssl_connection.erl",1678}}, I can submit the whole crash log if needed. On 08/02/2012 12:35 AM, Matthias Radestock wrote: > We got the following process crash report from a user running R15B01 > (trimmed somewhat to hide private key material): > > =CRASH REPORT==== 31-Jul-2012::11:49:27 === > crasher: > initial call: ssl_connection:init/1 > pid: <0.2005.0> > registered_name: [] > exception exit: {function_clause, > [{ssl_connection,handle_alert, > [{alert,1,41,{"ssl_connection.erl",1678}}, > certify, > {state,server, > {#Ref<0.0.0.3519>,<0.2004.0>}, > > gen_tcp,tcp,tcp_closed,tcp_error,"localhost",5673, > #Port<0.6927>, > {ssl_options,[],verify_peer, > {#Fun, > #Fun}, > false,false,undefined,1, > "C:/certstore/server/cert.pem",undefined, > > "C:/certstore/server/key.pem",undefined,undefined, > undefined,"C:/certstore/testca/cacert.pem", > undefined,undefined, > [<<0,57>>, > <<0,56>>, > <<0,53>>, > <<0,22>>, > <<0,19>>, > <<0,10>>, > <<0,51>>, > <<0,50>>, > <<0,47>>, > <<0,5>>, > <<0,4>>, > <<0,21>>, > <<0,9>>], > #Fun,true,268435456,false,[], > undefined,false}, > {socket_options,binary,0,0,0,false}, > {connection_states, ...}, > [],<<>>,<<>>, > {...}, > [...], > 262221, > {session, ...}, > 274512,ssl_session_cache, > {3,0}, > undefined,true,rsa,undefined, > {'RSAPrivateKey','two-prime', ...}, > {'DHParameter', ...}, > undefined,undefined,#Ref<0.0.0.3523>, > {<0.2004.0>,#Ref<0.0.0.3539>}, > 0,<<>>,true, > {false,first}, > undefined, > {[],[]}, > false,true}], > [{file,"ssl_connection.erl"},{line,2179}]}, > {ssl_connection,handle_alerts,2, > [{file,"ssl_connection.erl"},{line,2177}]}, > > {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,494}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,227}]}]} > in function gen_fsm:terminate/7 (gen_fsm.erl, line 611) > ancestors: [ssl_connection_sup,ssl_sup,<0.225.0>] > messages: [] > links: [<0.228.0>] > dictionary: [{ssl_manager,ssl_manager}] > trap_exit: false > status: running > heap_size: 2584 > stack_size: 24 > reductions: 2959 > neighbours: > > > Sure enough there's no handle_alert function clause that matches on an > #alert.description=41. Indeed that alert code isn't even mentioned at > ssl_alert.hrl or the rfc 2246 on which that list is supposedly based. It > is however shown in rfc 5246 as 'no_certificate_RESERVED', and, as > evidenced above, clearly can pop out of the ssl libraries under some > circumstances. > > > Regards, > > Matthias. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From hsvhome@REDACTED Thu Aug 2 09:09:32 2012 From: hsvhome@REDACTED (Sergey Shilov) Date: Thu, 2 Aug 2012 10:09:32 +0300 Subject: [erlang-bugs] missing function clause in ssl_connection:handle_alert In-Reply-To: <5019AF34.1060103@rabbitmq.com> References: <5019AF34.1060103@rabbitmq.com> Message-ID: <096783BB-5AD4-4EC7-85F5-03164C75AC40@mail.ru> On Aug 2, 2012, at 1:35 AM, Matthias Radestock wrote: > We got the following process crash report from a user running R15B01 (trimmed somewhat to hide private key material): > > =CRASH REPORT==== 31-Jul-2012::11:49:27 === > crasher: > initial call: ssl_connection:init/1 > pid: <0.2005.0> > registered_name: [] > exception exit: {function_clause, > [{ssl_connection,handle_alert, > [{alert,1,41,{"ssl_connection.erl",1678}}, > certify, > {state,server, > {#Ref<0.0.0.3519>,<0.2004.0>}, > gen_tcp,tcp,tcp_closed,tcp_error,"localhost",5673, > #Port<0.6927>, > {ssl_options,[],verify_peer, > {#Fun, > #Fun}, > false,false,undefined,1, > "C:/certstore/server/cert.pem",undefined, The problem is old and (probably) well-known http://erlang.2086793.n4.nabble.com/ssl-connection-crash-on-client-connect-w-o-certificte-tt3570411.html#none A possible solution included -------------- next part -------------- A non-text attachment was scrubbed... Name: otp-R15B-1c-ssl_crash_on_no_certificate.patch Type: application/octet-stream Size: 1830 bytes Desc: not available URL: -------------- next part -------------- Regards, Sergey. http://packages.altlinux.org/en/Sisyphus/srpms/erlang From matthias@REDACTED Thu Aug 2 10:52:31 2012 From: matthias@REDACTED (Matthias Radestock) Date: Thu, 02 Aug 2012 09:52:31 +0100 Subject: [erlang-bugs] missing function clause in ssl_connection:handle_alert In-Reply-To: <096783BB-5AD4-4EC7-85F5-03164C75AC40@mail.ru> References: <5019AF34.1060103@rabbitmq.com> <096783BB-5AD4-4EC7-85F5-03164C75AC40@mail.ru> Message-ID: <501A3FCF.7070508@rabbitmq.com> On 02/08/12 08:09, Sergey Shilov wrote: > The problem is old and (probably) well-known > > http://erlang.2086793.n4.nabble.com/ssl-connection-crash-on-client-connect-w-o-certificte-tt3570411.html#none Ah. I knew I should have done a search first. I see you got no reply to your original post. Shame that this still hasn't been fixed, more than a year later :( Matthias. From ali.sabil@REDACTED Thu Aug 2 15:55:13 2012 From: ali.sabil@REDACTED (Ali Sabil) Date: Thu, 2 Aug 2012 15:55:13 +0200 Subject: [erlang-bugs] missing function clause in ssl_connection:handle_alert In-Reply-To: <096783BB-5AD4-4EC7-85F5-03164C75AC40@mail.ru> References: <5019AF34.1060103@rabbitmq.com> <096783BB-5AD4-4EC7-85F5-03164C75AC40@mail.ru> Message-ID: On Thu, Aug 2, 2012 at 9:09 AM, Sergey Shilov wrote: > > On Aug 2, 2012, at 1:35 AM, Matthias Radestock wrote: > >> We got the following process crash report from a user running R15B01 (trimmed somewhat to hide private key material): >> >> =CRASH REPORT==== 31-Jul-2012::11:49:27 === >> crasher: >> initial call: ssl_connection:init/1 >> pid: <0.2005.0> >> registered_name: [] >> exception exit: {function_clause, >> [{ssl_connection,handle_alert, >> [{alert,1,41,{"ssl_connection.erl",1678}}, >> certify, >> {state,server, >> {#Ref<0.0.0.3519>,<0.2004.0>}, >> gen_tcp,tcp,tcp_closed,tcp_error,"localhost",5673, >> #Port<0.6927>, >> {ssl_options,[],verify_peer, >> {#Fun, >> #Fun}, >> false,false,undefined,1, >> "C:/certstore/server/cert.pem",undefined, > > > The problem is old and (probably) well-known > > http://erlang.2086793.n4.nabble.com/ssl-connection-crash-on-client-connect-w-o-certificte-tt3570411.html#none > > A possible solution included > > Maybe you could submit the patch to erlang-patches? > > > > Regards, > > Sergey. > > http://packages.altlinux.org/en/Sisyphus/srpms/erlang > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From hsvhome@REDACTED Thu Aug 2 17:24:45 2012 From: hsvhome@REDACTED (Sergey Shilov) Date: Thu, 2 Aug 2012 18:24:45 +0300 Subject: [erlang-bugs] missing function clause in ssl_connection:handle_alert In-Reply-To: References: <5019AF34.1060103@rabbitmq.com> <096783BB-5AD4-4EC7-85F5-03164C75AC40@mail.ru> Message-ID: <4F0AF16C-0CFF-43E2-8275-83F1725B9C05@mail.ru> On Aug 2, 2012, at 4:55 PM, Ali Sabil wrote: >> >> A possible solution included >> >> > > Maybe you could submit the patch to erlang-patches? > No problem :-) The patch is redirected to the "erlang-patches" mailing list. Regards. Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Aug 3 11:12:02 2012 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 3 Aug 2012 11:12:02 +0200 Subject: [erlang-bugs] bug in erlang:size Message-ID: I think this is a bug: $erl 1> B = <<1:17>>. <<0,0,1:1>> 2> size(B) 2 B is not a binary or tuple to size(B) should give badarg /Joe From wsmith@REDACTED Fri Aug 3 19:05:14 2012 From: wsmith@REDACTED (Warren Smith) Date: Fri, 3 Aug 2012 17:05:14 +0000 Subject: [erlang-bugs] bug decoding AuthorityKeyIdentifier in certificate? Message-ID: <4B5D885B77E8CC43852B8F0315AD03BA1AC346F4@EXMBX03.austin.utexas.edu> I've come across what may be a bug in the function dec_AuthorityKeyIdentifier(Tlv, TagIn) in OTP-PUB-Key.erl in version R15B01. A simple test program is: $ cat test_cert.erl -module(test_cert). -export([cert_file_to_db/1,cert_from_file/1]). cert_file_to_db(File) -> Db = ssl_certificate_db:create(), ssl_certificate_db:add_trusted_certs(self(), File, Db). cert_from_file(File) -> {ok, PemBin} = file:read_file(File), [PemEntry] = public_key:pem_decode(PemBin), {'Certificate', Cert, not_encrypted} = PemEntry, ErlCert = public_key:pkix_decode_cert(Cert, otp), io:format("~p~n",[ErlCert]). On this certificate: $ cat 5813ea38.0 -----BEGIN CERTIFICATE----- MIICgjCCAeugAwIBAgIBADANBgkqhkiG9w0BAQUFADA3MQ0wCwYDVQQKEwRBdXRv MRkwFwYDVQQLExBGdXR1cmVHcmlkTmltYnVzMQswCQYDVQQDEwJDQTAeFw0xMDA5 MDcxNjM0NDJaFw0xNTA5MDcxNjM0NTJaMDcxDTALBgNVBAoTBEF1dG8xGTAXBgNV BAsTEEZ1dHVyZUdyaWROaW1idXMxCzAJBgNVBAMTAkNBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQCyYqVUsHNqOUS+31s2zdMj7HTENnmdTxb+Ihbt50zl+L/o VTJkRWEw3Vy3F8KSbIHEfViDPAMBcpv2KZGZIZfCfGE9wfwEp/mcuEY/WA+jKSev lKFQXPWZQtP0OhwT7h2ZHYK/BA8gNvEpKmqvxm8Kb71v/HCXANYoZMwwgjNIcwID AQABo4GdMIGaMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFBhsOpAcfJATaaHH EeG7ff96svu2MFsGA1UdIwRUMFKAFBhsOpAcfJATaaHHEeG7ff96svu2oTcxDTAL BgNVBAoTBEF1dG8xGTAXBgNVBAsTEEZ1dHVyZUdyaWROaW1idXMxCzAJBgNVBAMT AkNBggEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOBgQCuaZaw8f8AmQg4 CiOMgR2qs1zqiXXDGJTx5mnvcDwgyWKqrsNj+8g9oh0R8fx29jUJvq82cVCk0mTR 6Yl/wlgFPFHveykA94AzMoHrVBdmusRJRN0B7GTCTnMCnSHhG0FBjagyqC92MZj4 qJRQswlft8SqfOTxezAZLRXSDJYvvw== -----END CERTIFICATE----- Results in: $ erl -noshell -s test_cert cert_from_file 5813ea38.0 -s init stop {"init terminating in do_boot",{{badmatch,{error,{asn1,{invalid_choice_tag,{17,[{16,[{6,<<3 bytes>>},{19,<<4 bytes>>}]}]}}}}},[{public_key,pkix_decode_cert,2,[{file,"public_key.erl"},{line,216}]},{test_cert,cert_from_file,1,[{file,"test_cert.erl"},{line,15}]},{init,start_it,1,[]},{init,start_em,1,[]}]}} Crash dump was written to: erl_crash.dump init terminating in do_boot () This certificate is handled ok by OpenSSL (e.g. openssl x509 -in 5813ea38.0 -text -noout) and by at least one Java X.509 implementation. I haven't looked in to the process of how public_key/asn1/OTP-PUB-KEY.erl is generated, but this block of code in the dec_AuthorityKeyIdentifier(Tlv, TagIn) function: %%------------------------------------------------- %% attribute authorityCertIssuer(2) External OTP-PUB-KEY:GeneralNames OPTIONAL %%------------------------------------------------- {Term2, Tlv3} = case Tlv2 of [{131073, V2} | TempTlv3] -> {dec_GeneralNames(V2, []), TempTlv3}; _ -> {asn1_NOVALUE, Tlv2} end, Is where the problem start showing up. For the above certificate, it is passing this to dec_GeneralNames(Tlv, TagIn): Tlv: [{17,[{16,[{6,<<85,4,10>>},{19,<<"Auto">>}]}]}, {17,[{16,[{6,<<85,4,11>>},{19,<<"FutureGridNimbus">>}]}]}, {17,[{16,[{6,<<85,4,3>>},{19,<<"CA">>}]}]}] TagIn: [] This doesn't look like what dec_GeneralNames() expects. It is close to what dec_Name() expects, though. There are perhaps 2 problems here. First, ({1310??, ???}, []) needs to be passed to dec_GeneralNames() not just (???, []). Second, 131076 should be associated with the above Tlv, not 131073. So, a hack of: %%------------------------------------------------- %% attribute authorityCertIssuer(2) External OTP-PUB-KEY:GeneralNames OPTIONAL %%------------------------------------------------- {Term2, Tlv3} = case Tlv2 of [{131073, V2} | TempTlv3] -> {dec_GeneralNames([{131076, {16, V2}}], []), TempTlv3}; _ -> {asn1_NOVALUE, Tlv2} end, Works around the problem for this certificate. What I haven't dug in to is why asn1rt_ber_bin_v2__decode(B, nif) is picking 131073 instead of 131076 (see below). I don't really understand what these numbers represent or where they are coming from so I'm not sure if there is a problem with the code, or with this certificate. However, from RFC 3280, it seems like it is valid to have a Name/RDN (or any other GeneralName) as the authorityCertIssuer. Maybe there is a restriction somewhere that I'm missing, though... decode(Type, Data) Type: 'AuthorityKeyIdentifier' Data: <<48,82,128,20,24,108,58,144,28,124,144,19,105,161,199,17,225,187,125, 255,122,178,251,182,161,55,49,13,48,11,6,3,85,4,10,19,4,65,117,116, 111,49,25,48,23,6,3,85,4,11,19,16,70,117,116,117,114,101,71,114,105, 100,78,105,109,98,117,115,49,11,48,9,6,3,85,4,3,19,2,67,65,130,1,0>> element: {16, [{131072, <<24,108,58,144,28,124,144,19,105,161,199,17,225,187,125,255, 122,178,251,182>>}, {131073, [{17,[{16,[{6,<<85,4,10>>},{19,<<"Auto">>}]}]}, {17,[{16,[{6,<<85,4,11>>},{19,<<"FutureGridNimbus">>}]}]}, {17,[{16,[{6,<<85,4,3>>},{19,<<"CA">>}]}]}]}, {131074,<<0>>}]} From wsmith@REDACTED Fri Aug 3 21:10:31 2012 From: wsmith@REDACTED (Warren Smith) Date: Fri, 3 Aug 2012 19:10:31 +0000 Subject: [erlang-bugs] bug decoding domain components in certificate? Message-ID: <4B5D885B77E8CC43852B8F0315AD03BA1AC3680F@EXMBX03.austin.utexas.edu> I've come across another problem with decoding some certificates in R15B01. An example certificate where the problem occurs is: $ cat 684261aa.0 -----BEGIN CERTIFICATE----- MIIEHTCCAwWgAwIBAgIBATANBgkqhkiG9w0BAQUFADBuMRMwEQYKCZImiZPyLGQB GRMDRURVMRYwFAYKCZImiZPyLGQBGRMGVVRFWEFTMRQwEgYKCZImiZPyLGQBGRME VEFDQzESMBAGA1UEChMJVVQtQVVTVElOMRUwEwYDVQQDEwxUQUNDIFJvb3QgQ0Ew HhcNMDgxMDAyMDM1NjAyWhcNMTgwOTMwMDM1NjAyWjBuMRMwEQYKCZImiZPyLGQB GRMDRURVMRYwFAYKCZImiZPyLGQBGRMGVVRFWEFTMRQwEgYKCZImiZPyLGQBGRME VEFDQzESMBAGA1UEChMJVVQtQVVTVElOMRUwEwYDVQQDEwxUQUNDIFJvb3QgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwlD+7dc8Am/rnd1bvvyW+ UGlkXb3KxlObgmlx0RdznJvWrxCPz4/nfvk87toUX2L4fxv3/mO3Q6n0UVFc83og oJlNh8oqNJuVotH6jg+e65XD0z4QSNSgLVAWGV/9TU93PGUALgfXJFng3VbJ/Ljb o01RbOQjOD7e5VJIx52wlOiyaMQlaV0yZ4C5OxgpKR/X2xMtqbuCGVIieeOBJtzg cvatyuEIZBSHA/qhX51Rqrfc8MtKeZ/Zu7K4v0RC77bolptsAg36LCRR1T9BcyJx Gv+yj52m5bPBuJj6ALEx/CkI6fAmkDGLvtIwZJRByrN8BdXYrBme6q0NChJg1pPR AgMAyfujgcUwgcIwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUjXUjaNFVmWzD ph6G/N/EU+jlU8cwHwYDVR0jBBgwFoAUjXUjaNFVmWzDph6G/N/EU+jlU8cwDgYD VR0PAQH/BAQDAgEGMB0GA1UdEQQWMBSBEmNhQHRhY2MudXRleGFzLmVkdTBABgNV HR8EOTA3MDWgM6Axhi9odHRwOi8vd3d3LnRhY2MudXRleGFzLmVkdS9DQS9UQUND X1Jvb3RfQ1JMLmRlcjANBgkqhkiG9w0BAQUFAAOCAQEAm7B3gK4RiE50ct2cAbhT dD1BOHXVIIb312ZlqB6IqwM+EFfo4HW82/bDbfPfF8QZMvESuRkFl0mVK5hYPT12 VWsQC5sX6wz1ps5dgoaJ+lLZbgb3pStnN0lZEAfufMog98GM+DW6YnJaWIYpv2Mv QbRYInGZAYWHR2GJbUjyKh2u0sJZOHJjffDL4NCUsA2thaKDcE0CG8bjwikYEVHX j6GTY5rLsKW2NfJ8VU40dPEGjtWMOsC0HFoy27Nj5Gi2j6WpRD49EKN7+pg6Dy2I Em9R60Sl6WhKgo//3+mg8/mZqsqCQSq5BNa7M5ltyx1RgFPoRhKlTDXLDzxVEFNk Cg== -----END CERTIFICATE----- A simple test program is: $ cat test_cert.erl -module(test_cert). -export([cert_file_to_db/1,cert_from_file/1]). cert_file_to_db(File) -> Db = ssl_certificate_db:create(), ssl_certificate_db:add_trusted_certs(self(), File, Db). cert_from_file(File) -> {ok, PemBin} = file:read_file(File), [PemEntry] = public_key:pem_decode(PemBin), {'Certificate', Cert, not_encrypted} = PemEntry, ErlCert = public_key:pkix_decode_cert(Cert, otp), io:format("~p~n",[ErlCert]). And the error I see is: $ erl -noshell -s test_cert cert_from_file 684261aa.0 -s init stop {"init terminating in do_boot",{{badmatch,{error,{asn1,{{case_clause,22},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14128}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,499}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,189}]},{pubkey_cert_records,decode_cert,1,[{file,"pubkey_cert_records.erl"},{line,40}]},{public_key,pkix_decode_cert,2,[{file,"public_key.erl"},{line,211}]}]}}}},[{public_key,pkix_decode_cert,2,[{file,"public_key.erl"},{line,215}]},{test_cert,cert_from_file,1,[{file,"test_cert.erl"},{line,15}]},{init,start_it,1,[]},{init,start_em,1,[]}]}} Crash dump was written to: erl_crash.dump init terminating in do_boot () I see that dec_DomainComponent(Tlv, TagIn) gets arguments: Tlv: {19,<<"EDU">>} TagIn: [22] And this results (after a couple levels of function calls) in match_tags() returning: {error,{asn1,{wrong_tag,{19,22}}}} It looks like this certificate has domain components that use the type poste-restante-address (19) while the erlang code expects extended-network-address (22). I'm not entirely sure what the correct behavior should be. I spent some time looking around the X.509-related RFCs and didn't manage to find constraints on what types can be used in domain components. This certificate is handled ok by OpenSSL (e.g. openssl x509 -in 5813ea38.0 -text -noout) and by at least one Java X.509 implementation, though. I just did a work around by changing dec_DomainComponent() from: dec_DomainComponent(Tlv) -> dec_DomainComponent(Tlv, [22]). To: dec_DomainComponent(Tlv) -> {Tag, Data} = Tlv, case Tag of 19 -> decode_restricted_string(Tlv, [], Tag, [Tag]); 22 -> decode_restricted_string(Tlv, [], Tag, [Tag]) end. From steven.charles.davis@REDACTED Sat Aug 4 01:06:29 2012 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 3 Aug 2012 16:06:29 -0700 (PDT) Subject: [erlang-bugs] [erlang-questions] bug in erlang:size In-Reply-To: References: Message-ID: <19d7d9d8-acdb-4ac3-943e-1944ac8b88e2@googlegroups.com> 3> byte_size(B). 3 On Friday, August 3, 2012 4:12:02 AM UTC-5, Joe Armstrong wrote: > > I think this is a bug: > > $erl > 1> B = <<1:17>>. > <<0,0,1:1>> > 2> size(B) > 2 > > > B is not a binary or tuple to size(B) should give badarg > > /Joe > _______________________________________________ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Sat Aug 4 01:35:01 2012 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 03 Aug 2012 16:35:01 -0700 Subject: [erlang-bugs] [erlang-questions] bug in erlang:size In-Reply-To: <19d7d9d8-acdb-4ac3-943e-1944ac8b88e2@googlegroups.com> References: <19d7d9d8-acdb-4ac3-943e-1944ac8b88e2@googlegroups.com> Message-ID: <501C6025.6000107@gmail.com> 4> byte_size(B). 2.125 On 08/03/2012 04:06 PM, Steve Davis wrote: > 3> byte_size(B). > 3 > > > On Friday, August 3, 2012 4:12:02 AM UTC-5, Joe Armstrong wrote: > > I think this is a bug: > > $erl > 1> B = <<1:17>>. > <<0,0,1:1>> > 2> size(B) > 2 > > > B is not a binary or tuple to size(B) should give badarg > > /Joe > _______________________________________________ > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Sat Aug 4 08:29:21 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Sat, 04 Aug 2012 08:29:21 +0200 Subject: [erlang-bugs] bug in erlang:size In-Reply-To: References: Message-ID: <501CC141.2020301@cs.ntua.gr> On 08/03/2012 11:12 AM, Joe Armstrong wrote: > I think this is a bug: > > $erl > 1> B =<<1:17>>. > <<0,0,1:1>> > 2> size(B). > 2 > > > B is not a binary or tuple to size(B) should give badarg There is indeed something fishy in the above... But IMO, size/1 is one of these functions that should be considered deprecated and only kept for backwards compatibility. These days there exist built-in functions tuple_size/1, byte_size/1, and bit_size/1 that are unambiguous and more type-friendly. I would urge Joe to avoid mentioning the existence of size/1 in the new edition of his book. Kostis From robert.virding@REDACTED Sat Aug 4 14:16:26 2012 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 04 Aug 2012 13:16:26 +0100 (BST) Subject: [erlang-bugs] bug in erlang:size In-Reply-To: <501CC141.2020301@cs.ntua.gr> Message-ID: ----- Original Message ----- > On 08/03/2012 11:12 AM, Joe Armstrong wrote: > > I think this is a bug: > > > > $erl > > 1> B =<<1:17>>. > > <<0,0,1:1>> > > 2> size(B). > > 2 > > > > > > B is not a binary or tuple to size(B) should give badarg > > There is indeed something fishy in the above... > > But IMO, size/1 is one of these functions that should be considered > deprecated and only kept for backwards compatibility. These days > there > exist built-in functions tuple_size/1, byte_size/1, and bit_size/1 > that > are unambiguous and more type-friendly. > > I would urge Joe to avoid mentioning the existence of size/1 in the > new > edition of his book. I agree with Kostis here. Don't mention it or if he does mention it then it should be so they can understand old code but with a word of warning not to use it. I understand why it should work with bit strings, it would be strange if it didn't as it works on binaries. Though I think it should return 3 not 2, as byte_size/1 does for the same bit string in R15B01. Robert From erlang@REDACTED Sat Aug 4 18:26:03 2012 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 4 Aug 2012 18:26:03 +0200 Subject: [erlang-bugs] bug in erlang:size In-Reply-To: <501CC141.2020301@cs.ntua.gr> References: <501CC141.2020301@cs.ntua.gr> Message-ID: On Sat, Aug 4, 2012 at 8:29 AM, Kostis Sagonas wrote: > On 08/03/2012 11:12 AM, Joe Armstrong wrote: >> >> I think this is a bug: >> >> $erl >> 1> B =<<1:17>>. >> <<0,0,1:1>> >> 2> size(B). >> >> 2 >> >> >> B is not a binary or tuple to size(B) should give badarg > > > There is indeed something fishy in the above... > > But IMO, size/1 is one of these functions that should be considered > deprecated and only kept for backwards compatibility. These days there > exist built-in functions tuple_size/1, byte_size/1, and bit_size/1 that are > unambiguous and more type-friendly. > > I would urge Joe to avoid mentioning the existence of size/1 in the new > edition of his book. Point taken - size will vanish /Joe > Kostis > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From tuncer.ayaz@REDACTED Mon Aug 6 19:42:03 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 6 Aug 2012 19:42:03 +0200 Subject: [erlang-bugs] erlang.el indenter Message-ID: There seems to be a bug in the indenter that mis-indents rebar.erl:commands/0, if it's indented as part of a larger region. The multi-line binary string seems to be the problem. rebar.erl:commands/0: https://github.com/basho/rebar/blob/491d52298e2/src/rebar.erl#L275-311 It works correctly when indenting the function itself with C-c C-q. From tuncer.ayaz@REDACTED Mon Aug 6 19:43:36 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 6 Aug 2012 19:43:36 +0200 Subject: [erlang-bugs] Spec or Dialyzer regression In-Reply-To: References: <4FB2BB82.7000303@cs.ntua.gr> Message-ID: On Wed, May 16, 2012 at 4:54 PM, Tuncer Ayaz wrote: > On Wed, 16 May 2012 01:24:21 +0200, Tuncer Ayaz wrote: > >> On Tue, May 15, 2012 at 10:24 PM, Kostis Sagonas wrote: >> > On 05/15/2012 09:50 PM, Tuncer Ayaz wrote: >> > > >> > > There seems to be a spec or Dialyzer regression in otp master >> > > revealed when dialyzing rebar. >> > >> > Since Tuncer did not submit all the info he has, let me add that the >> > behavior reported in his mail exists in the *master* branch of OTP >> > and *not* in the maint branch which works correctly in rebar's code >> > base. >> >> Forgot to test with maint, but will do. That's why it's not mentioned. > > Checked, maint results are the same as R15B01. > >> > It's unlikely that this is a dialyzer issue, as AFAIK dialyzer's >> > code is the same in these two branches, but it's most likely either >> > due to some erroneous spec that was introduced/changed in the master >> > branch or a problem in rebar's code base. >> >> Upon review of the rebar code which provokes the warnings, the >> substantial changes to erl_bif_types seem like a good candidate for >> further analysis (commits bd941f50 03715097 9d870a01). Maybe the >> changes are not finished yet. >> >> > IMO, Tuncer should have checked the latter before filling the >> > report. It would be nice if he did that. >> >> That's a good idea. I will git bisect rebar. > > Done, found no erroneous commit in rebar. Any update on this bug? From daniel@REDACTED Thu Aug 9 00:43:45 2012 From: daniel@REDACTED (Daniel Luna) Date: Wed, 8 Aug 2012 18:43:45 -0400 Subject: [erlang-bugs] Crash in SSL Message-ID: We are experiencing a crash in ssl when trying to establish connections to websites with seemingly valid ssl certificates. Going to the following domains in a normal web browser will give a green light. Trying to connect to them using ssl:connect gives a crash. This crash occurs even with verify_none turned on. Some example domains are www.farmbureaubank.com and login.secureserver.net ssl:connect is working in general which is shown by the google.com example. Cheers, Daniel 1> ssl:connect("google.com", 443, [], infinity). {ok,{sslsocket,new_ssl,<0.8447.0>}} 2> ssl:connect("login.secureserver.net", 443, [{verify, verify_none}], infinity). ** exception exit: {{{badmatch, {error, {asn1, {{case_clause,19}, [{'OTP-PUB-KEY', check_and_convert_restricted_string,5, [{file,"OTP-PUB-KEY.erl"}, {line,14122}]}, {'OTP-PUB-KEY',decode,2, [{file,"OTP-PUB-KEY.erl"},{line,493}]}, {pubkey_cert_records,transform,2, [{file,"pubkey_cert_records.erl"}, {line,60}]}, {lists,map,2, [{file,"lists.erl"},{line,1173}]}, {pubkey_cert_records,transform,2, [{file,"pubkey_cert_records.erl"}, {line,72}]}, {pubkey_cert_records,decode_tbs,1, [{file,"pubkey_cert_records.erl"}, {line,190}]}, {pubkey_cert_records,decode_cert,1, [{file,"pubkey_cert_records.erl"}, {line,40}]}, {public_key,pkix_decode_cert,2, [{file,"public_key.erl"}, {line,211}]}]}}}}, [{public_key,pkix_decode_cert,2, [{file,"public_key.erl"},{line,215}]}, {public_key,path_validation,2, [{file,"public_key.erl"},{line,605}]}, {ssl_handshake,certify,7, [{file,"ssl_handshake.erl"},{line,218}]}, {ssl_connection,certify,2, [{file,"ssl_connection.erl"},{line,514}]}, {ssl_connection,next_state,4, [{file,"ssl_connection.erl"},{line,1929}]}, {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,494}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,227}]}]}, {gen_fsm,sync_send_all_state_event, [<0.8453.0>,start,infinity]}} in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 240) in call from ssl_connection:sync_send_all_state_event/3 (ssl_connection.erl, line 1195) in call from ssl_connection:handshake/2 (ssl_connection.erl, line 167) in call from ssl_connection:start_fsm/8 (ssl_connection.erl, line 1037) in call from ssl_connection:connect/7 (ssl_connection.erl, line 139) 18:40:19.798 [error] gen_fsm <0.8453.0> in state certify terminated with reason: no match of right hand value {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} in public_key:pkix_decode_cert/2 line 215 18:40:19.931 [error] CRASH REPORT Process <0.8453.0> with 0 neighbours exited with reason: no match of right hand value {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} in public_key:pkix_decode_cert/2 line 215 in gen_fsm:terminate/7 line 611 18:40:19.970 [error] Supervisor ssl_connection_sup had child undefined started with {ssl_connection,start_link,undefined} at <0.8453.0> exit with reason no match of right hand value {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} in public_key:pkix_decode_cert/2 line 215 in context child_terminated From jimmyruska@REDACTED Fri Aug 10 19:17:25 2012 From: jimmyruska@REDACTED (Jimmy Ruska) Date: Fri, 10 Aug 2012 12:17:25 -0500 Subject: [erlang-bugs] gb_trees:from_orddict loses data? Message-ID: I was benchmarking different things and I came across this weird behavior. 1> gb_trees:lookup(6619,gb_trees:from_orddict([ {N,N} || N <- [6619,1]])). none 2> gb_trees:lookup(6619,gb_trees:from_orddict([ {N,N} || N <- [1,6619,2]])). {value,6619} 3> gb_trees:from_orddict([ {N,N} || N <- [6619,1]]). {2,{1,1,{6619,6619,nil,nil},nil}} It's supposed to be {Size, {Key, Val, Smaller, Bigger}} but the value that's bigger is in the smaller part. It's still in there but it doesn't find it. If I insert manually it's no problem. The Tree is structured differently. 4> gb_trees:lookup(6619,lists:foldl(fun(N,T) -> gb_trees:enter(N,N,T) end,gb_trees:empty(),[6619,1])). {value,6619} 5> lists:foldr(fun(N,T) -> gb_trees:enter(N,N,T) end,gb_trees:empty(),[6619,1]). {2,{1,1,nil,{6619,6619,nil,nil}}} The number 6619 has no relevance, switch in any number. 6> gb_trees:lookup(2,gb_trees:from_orddict([{2, 2}, {1, 1}])). none It also doesn't matter how many elements are in the list. - Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: From huntermorris@REDACTED Fri Aug 10 19:23:47 2012 From: huntermorris@REDACTED (Hunter Morris) Date: Fri, 10 Aug 2012 18:23:47 +0100 Subject: [erlang-bugs] gb_trees:from_orddict loses data? In-Reply-To: References: Message-ID: >From the gb_trees:from_orddict/1 documentation: "Turns an ordered list List of key-value tuples into a tree. The list must not contain duplicate keys." None of the failing examples you provide are of ordered lists. If you modify your first example like so: 1> gb_trees:lookup(6619, gb_trees:from_orddict([ {N, N} || N <- lists:sort([6619, 1])])). {value,6619} It behaves as expected for your other examples as well. Best, Hunter On Fri, Aug 10, 2012 at 6:17 PM, Jimmy Ruska wrote: > I was benchmarking different things and I came across this weird behavior. > > 1> gb_trees:lookup(6619,gb_trees:from_orddict([ {N,N} || N <- [6619,1]])). > none > > 2> gb_trees:lookup(6619,gb_trees:from_orddict([ {N,N} || N <- [1,6619,2]])). > {value,6619} > > 3> gb_trees:from_orddict([ {N,N} || N <- [6619,1]]). > {2,{1,1,{6619,6619,nil,nil},nil}} > > It's supposed to be {Size, {Key, Val, Smaller, Bigger}} but the value that's > bigger is in the smaller part. It's still in there but it doesn't find it. > > If I insert manually it's no problem. The Tree is structured differently. > > 4> gb_trees:lookup(6619,lists:foldl(fun(N,T) -> gb_trees:enter(N,N,T) > end,gb_trees:empty(),[6619,1])). > {value,6619} > > 5> lists:foldr(fun(N,T) -> gb_trees:enter(N,N,T) > end,gb_trees:empty(),[6619,1]). > {2,{1,1,nil,{6619,6619,nil,nil}}} > > The number 6619 has no relevance, switch in any number. > > 6> gb_trees:lookup(2,gb_trees:from_orddict([{2, 2}, {1, 1}])). > none > > It also doesn't matter how many elements are in the list. > > - Jimmy > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From tuncer.ayaz@REDACTED Fri Aug 10 19:53:01 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 10 Aug 2012 19:53:01 +0200 Subject: [erlang-bugs] Nameless function in Kernel Reference Manual Message-ID: The 'packages' module/chapter in the Kernel Reference Manual links to an unnamed function with arity /0. 1. go to http://www.erlang.org/doc/apps/kernel/index.html 2. open the section "packages" 3. click on "/0" http://www.erlang.org/doc/man/packages.html#-0 From emile@REDACTED Sat Aug 11 01:24:19 2012 From: emile@REDACTED (Emile Joubert) Date: Sat, 11 Aug 2012 00:24:19 +0100 Subject: [erlang-bugs] Non-ASCII xref paths fail Message-ID: <50259823.1090502@rabbitmq.com> Hi, We are seeing xref errors when paths contain non-ASCII characters. This makes it impossible to compile .script files when directories contain non-ASCII characters: {error,xref_base, {invalid_filename,[ ...130,172,195,182... ]}} xref_utils:is_string/2 enforces the overly conservative upper limit of 126 in character codes. -Emile From kenneth.lundin@REDACTED Mon Aug 13 14:59:11 2012 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 13 Aug 2012 14:59:11 +0200 Subject: [erlang-bugs] bug decoding AuthorityKeyIdentifier in certificate? In-Reply-To: <4B5D885B77E8CC43852B8F0315AD03BA1AC346F4@EXMBX03.austin.utexas.edu> References: <4B5D885B77E8CC43852B8F0315AD03BA1AC346F4@EXMBX03.austin.utexas.edu> Message-ID: Hi Warren, I have looked at this and suspect that the certificate you have does not follow the standard correctly when it comes to the extension of type AuthorityKeyIdentifier. AuthorityKeyIdentifier is specified as this: AuthorityKeyIdentifier ::= SEQUENCE { keyIdentifier [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } -- authorityCertIssuer and authorityCertSerialNumber MUST both -- be present or both be absent On the TLV level of decoding your data decodes to: {16, [{131072, <<24,108,58,144,28,124,144,19,105,161,199,17,225,187,125, 255,122,178,251,182>>}, {131073, [{17,[{16,[{6,<<85,4,10>>},{19,<<"Auto">>}]}]}, {17,[{16,[{6,<<85,4,11>>},{19,<<"FutureGridNimbus">>}]}]}, {17,[{16,[{6,<<85,4,3>>},{19,<<"CA">>}]}]}]}, {131074,<<0>>}]}, where {131072, ... is the keyidentifier [0] {131073,... is authorityCertIssuer [1] GeneralNames {131074, ... is authorityCertSerialNumber [2] The tag values 131072, ... etc are decimal and not easy to understand. But converted to hex they make more sense since 131072 in hex is #20000 The value is composed of 2 bits representing the class of the tag followed by 16 bits representing the tag-value so here we have class = 2, tagvalue = 0 131073 = #20001 = class (2), tagvalue (1) etc. GeneralNames is defined as follows GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName GeneralName ::= CHOICE { otherName [0] AnotherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } As far as I understand the data for CHOICE level is missing in the certificate. The data as it is now seems to be a sequence of Name instead of as it should be a sequence of GeneralName with the CHOICE-alternative directoryName (tag [4] which explains 131076 in the workaround since it corresponds to the tag [4]. I don't know why this certificate works in other implementations, maybe it is because the data in the extension AuthorityKeyIdentifier is not really necessary in the use case and therefore not decoded in the other implementations? How is this certificate created? /Kenneth Erlang7OTP, Ericsson On 8/3/12, Warren Smith wrote: > > I've come across what may be a bug in the function > dec_AuthorityKeyIdentifier(Tlv, TagIn) in OTP-PUB-Key.erl in version > R15B01. > > A simple test program is: > > $ cat test_cert.erl > > -module(test_cert). > -export([cert_file_to_db/1,cert_from_file/1]). > > cert_file_to_db(File) -> > Db = ssl_certificate_db:create(), > ssl_certificate_db:add_trusted_certs(self(), File, Db). > > cert_from_file(File) -> > {ok, PemBin} = file:read_file(File), > > [PemEntry] = public_key:pem_decode(PemBin), > {'Certificate', Cert, not_encrypted} = PemEntry, > > ErlCert = public_key:pkix_decode_cert(Cert, otp), > io:format("~p~n",[ErlCert]). > > On this certificate: > > $ cat 5813ea38.0 > > -----BEGIN CERTIFICATE----- > MIICgjCCAeugAwIBAgIBADANBgkqhkiG9w0BAQUFADA3MQ0wCwYDVQQKEwRBdXRv > MRkwFwYDVQQLExBGdXR1cmVHcmlkTmltYnVzMQswCQYDVQQDEwJDQTAeFw0xMDA5 > MDcxNjM0NDJaFw0xNTA5MDcxNjM0NTJaMDcxDTALBgNVBAoTBEF1dG8xGTAXBgNV > BAsTEEZ1dHVyZUdyaWROaW1idXMxCzAJBgNVBAMTAkNBMIGfMA0GCSqGSIb3DQEB > AQUAA4GNADCBiQKBgQCyYqVUsHNqOUS+31s2zdMj7HTENnmdTxb+Ihbt50zl+L/o > VTJkRWEw3Vy3F8KSbIHEfViDPAMBcpv2KZGZIZfCfGE9wfwEp/mcuEY/WA+jKSev > lKFQXPWZQtP0OhwT7h2ZHYK/BA8gNvEpKmqvxm8Kb71v/HCXANYoZMwwgjNIcwID > AQABo4GdMIGaMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFBhsOpAcfJATaaHH > EeG7ff96svu2MFsGA1UdIwRUMFKAFBhsOpAcfJATaaHHEeG7ff96svu2oTcxDTAL > BgNVBAoTBEF1dG8xGTAXBgNVBAsTEEZ1dHVyZUdyaWROaW1idXMxCzAJBgNVBAMT > AkNBggEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOBgQCuaZaw8f8AmQg4 > CiOMgR2qs1zqiXXDGJTx5mnvcDwgyWKqrsNj+8g9oh0R8fx29jUJvq82cVCk0mTR > 6Yl/wlgFPFHveykA94AzMoHrVBdmusRJRN0B7GTCTnMCnSHhG0FBjagyqC92MZj4 > qJRQswlft8SqfOTxezAZLRXSDJYvvw== > -----END CERTIFICATE----- > > Results in: > > $ erl -noshell -s test_cert cert_from_file 5813ea38.0 -s init stop > {"init terminating in > do_boot",{{badmatch,{error,{asn1,{invalid_choice_tag,{17,[{16,[{6,<<3 > bytes>>},{19,<<4 > bytes>>}]}]}}}}},[{public_key,pkix_decode_cert,2,[{file,"public_key.erl"},{line,216}]},{test_cert,cert_from_file,1,[{file,"test_cert.erl"},{line,15}]},{init,start_it,1,[]},{init,start_em,1,[]}]}} > > Crash dump was written to: erl_crash.dump > init terminating in do_boot () > > > This certificate is handled ok by OpenSSL (e.g. openssl x509 -in 5813ea38.0 > -text -noout) and by at least one Java X.509 implementation. > > I haven't looked in to the process of how public_key/asn1/OTP-PUB-KEY.erl is > generated, but this block of code in the dec_AuthorityKeyIdentifier(Tlv, > TagIn) function: > > %%------------------------------------------------- > %% attribute authorityCertIssuer(2) External OTP-PUB-KEY:GeneralNames > OPTIONAL > %%------------------------------------------------- > {Term2, Tlv3} = case Tlv2 of > [{131073, V2} | TempTlv3] -> > {dec_GeneralNames(V2, []), TempTlv3}; > _ -> {asn1_NOVALUE, Tlv2} > end, > > Is where the problem start showing up. For the above certificate, it is > passing this to dec_GeneralNames(Tlv, TagIn): > > Tlv: [{17,[{16,[{6,<<85,4,10>>},{19,<<"Auto">>}]}]}, > {17,[{16,[{6,<<85,4,11>>},{19,<<"FutureGridNimbus">>}]}]}, > {17,[{16,[{6,<<85,4,3>>},{19,<<"CA">>}]}]}] > TagIn: [] > > This doesn't look like what dec_GeneralNames() expects. It is close to what > dec_Name() expects, though. > > There are perhaps 2 problems here. First, ({1310??, ???}, []) needs to be > passed to dec_GeneralNames() not just (???, []). Second, 131076 should be > associated with the above Tlv, not 131073. > > So, a hack of: > > %%------------------------------------------------- > %% attribute authorityCertIssuer(2) External OTP-PUB-KEY:GeneralNames > OPTIONAL > %%------------------------------------------------- > {Term2, Tlv3} = case Tlv2 of > [{131073, V2} | TempTlv3] -> > {dec_GeneralNames([{131076, {16, V2}}], []), > TempTlv3}; > _ -> {asn1_NOVALUE, Tlv2} > end, > > Works around the problem for this certificate. > > What I haven't dug in to is why asn1rt_ber_bin_v2__decode(B, nif) is picking > 131073 instead of 131076 (see below). I don't really understand what these > numbers represent or where they are coming from so I'm not sure if there is > a problem with the code, or with this certificate. However, from RFC 3280, > it seems like it is valid to have a Name/RDN (or any other GeneralName) as > the authorityCertIssuer. Maybe there is a restriction somewhere that I'm > missing, though... > > > decode(Type, Data) > Type: 'AuthorityKeyIdentifier' > Data: > <<48,82,128,20,24,108,58,144,28,124,144,19,105,161,199,17,225,187,125, > > 255,122,178,251,182,161,55,49,13,48,11,6,3,85,4,10,19,4,65,117,116, > > 111,49,25,48,23,6,3,85,4,11,19,16,70,117,116,117,114,101,71,114,105, > > 100,78,105,109,98,117,115,49,11,48,9,6,3,85,4,3,19,2,67,65,130,1,0>> > element: {16, > [{131072, > <<24,108,58,144,28,124,144,19,105,161,199,17,225,187,125,255, > 122,178,251,182>>}, > {131073, > [{17,[{16,[{6,<<85,4,10>>},{19,<<"Auto">>}]}]}, > {17,[{16,[{6,<<85,4,11>>},{19,<<"FutureGridNimbus">>}]}]}, > {17,[{16,[{6,<<85,4,3>>},{19,<<"CA">>}]}]}]}, > {131074,<<0>>}]} > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From gustav@REDACTED Tue Aug 14 15:42:03 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Tue, 14 Aug 2012 15:42:03 +0200 Subject: [erlang-bugs] Nameless function in Kernel Reference Manual In-Reply-To: References: Message-ID: <502A55AB.20801@erlang.org> Hi, We'll remove it from the packages documentation page. Thank you for the report! Regards, Gustav Simonsson Erlang/OTP team Am 2012-08-10 19:53, schrieb Tuncer Ayaz: > The 'packages' module/chapter in the Kernel Reference Manual > links to an unnamed function with arity /0. > > 1. go to http://www.erlang.org/doc/apps/kernel/index.html > 2. open the section "packages" > 3. click on "/0" http://www.erlang.org/doc/man/packages.html#-0 > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From wsmith@REDACTED Tue Aug 14 21:29:27 2012 From: wsmith@REDACTED (Warren Smith) Date: Tue, 14 Aug 2012 19:29:27 +0000 Subject: [erlang-bugs] bug decoding AuthorityKeyIdentifier in certificate? In-Reply-To: References: <4B5D885B77E8CC43852B8F0315AD03BA1AC346F4@EXMBX03.austin.utexas.edu> Message-ID: <4B5D885B77E8CC43852B8F0315AD03BA1AC438F3@EXMBX01.austin.utexas.edu> Thanks for taking a look at this. Your explanation makes sense and it may be that other implementations ignore the problem because that information isn't needed. I believed the certificate was generated using OpenSSL, but I don't know what sort of configuration was used. I'll see if we can generate a new certificate that does the right thing. Thanks again, Warren -----Original Message----- From: Kenneth Lundin [mailto:kenneth.lundin@REDACTED] Sent: Monday, August 13, 2012 7:59 AM To: Warren Smith Cc: erlang-bugs@REDACTED Subject: Re: [erlang-bugs] bug decoding AuthorityKeyIdentifier in certificate? Hi Warren, I have looked at this and suspect that the certificate you have does not follow the standard correctly when it comes to the extension of type AuthorityKeyIdentifier. AuthorityKeyIdentifier is specified as this: AuthorityKeyIdentifier ::= SEQUENCE { keyIdentifier [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } -- authorityCertIssuer and authorityCertSerialNumber MUST both -- be present or both be absent On the TLV level of decoding your data decodes to: {16, [{131072, <<24,108,58,144,28,124,144,19,105,161,199,17,225,187,125, 255,122,178,251,182>>}, {131073, [{17,[{16,[{6,<<85,4,10>>},{19,<<"Auto">>}]}]}, {17,[{16,[{6,<<85,4,11>>},{19,<<"FutureGridNimbus">>}]}]}, {17,[{16,[{6,<<85,4,3>>},{19,<<"CA">>}]}]}]}, {131074,<<0>>}]}, where {131072, ... is the keyidentifier [0] {131073,... is authorityCertIssuer [1] GeneralNames {131074, ... is authorityCertSerialNumber [2] The tag values 131072, ... etc are decimal and not easy to understand. But converted to hex they make more sense since 131072 in hex is #20000 The value is composed of 2 bits representing the class of the tag followed by 16 bits representing the tag-value so here we have class = 2, tagvalue = 0 131073 = #20001 = class (2), tagvalue (1) etc. GeneralNames is defined as follows GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName GeneralName ::= CHOICE { otherName [0] AnotherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } As far as I understand the data for CHOICE level is missing in the certificate. The data as it is now seems to be a sequence of Name instead of as it should be a sequence of GeneralName with the CHOICE-alternative directoryName (tag [4] which explains 131076 in the workaround since it corresponds to the tag [4]. I don't know why this certificate works in other implementations, maybe it is because the data in the extension AuthorityKeyIdentifier is not really necessary in the use case and therefore not decoded in the other implementations? How is this certificate created? /Kenneth Erlang7OTP, Ericsson On 8/3/12, Warren Smith wrote: > > I've come across what may be a bug in the function > dec_AuthorityKeyIdentifier(Tlv, TagIn) in OTP-PUB-Key.erl in version > R15B01. > > A simple test program is: > > $ cat test_cert.erl > > -module(test_cert). > -export([cert_file_to_db/1,cert_from_file/1]). > > cert_file_to_db(File) -> > Db = ssl_certificate_db:create(), > ssl_certificate_db:add_trusted_certs(self(), File, Db). > > cert_from_file(File) -> > {ok, PemBin} = file:read_file(File), > > [PemEntry] = public_key:pem_decode(PemBin), > {'Certificate', Cert, not_encrypted} = PemEntry, > > ErlCert = public_key:pkix_decode_cert(Cert, otp), > io:format("~p~n",[ErlCert]). > > On this certificate: > > $ cat 5813ea38.0 > > -----BEGIN CERTIFICATE----- > MIICgjCCAeugAwIBAgIBADANBgkqhkiG9w0BAQUFADA3MQ0wCwYDVQQKEwRBdXRv > MRkwFwYDVQQLExBGdXR1cmVHcmlkTmltYnVzMQswCQYDVQQDEwJDQTAeFw0xMDA5 > MDcxNjM0NDJaFw0xNTA5MDcxNjM0NTJaMDcxDTALBgNVBAoTBEF1dG8xGTAXBgNV > BAsTEEZ1dHVyZUdyaWROaW1idXMxCzAJBgNVBAMTAkNBMIGfMA0GCSqGSIb3DQEB > AQUAA4GNADCBiQKBgQCyYqVUsHNqOUS+31s2zdMj7HTENnmdTxb+Ihbt50zl+L/o > VTJkRWEw3Vy3F8KSbIHEfViDPAMBcpv2KZGZIZfCfGE9wfwEp/mcuEY/WA+jKSev > lKFQXPWZQtP0OhwT7h2ZHYK/BA8gNvEpKmqvxm8Kb71v/HCXANYoZMwwgjNIcwID > AQABo4GdMIGaMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFBhsOpAcfJATaaHH > EeG7ff96svu2MFsGA1UdIwRUMFKAFBhsOpAcfJATaaHHEeG7ff96svu2oTcxDTAL > BgNVBAoTBEF1dG8xGTAXBgNVBAsTEEZ1dHVyZUdyaWROaW1idXMxCzAJBgNVBAMT > AkNBggEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOBgQCuaZaw8f8AmQg4 > CiOMgR2qs1zqiXXDGJTx5mnvcDwgyWKqrsNj+8g9oh0R8fx29jUJvq82cVCk0mTR > 6Yl/wlgFPFHveykA94AzMoHrVBdmusRJRN0B7GTCTnMCnSHhG0FBjagyqC92MZj4 > qJRQswlft8SqfOTxezAZLRXSDJYvvw== > -----END CERTIFICATE----- > > Results in: > > $ erl -noshell -s test_cert cert_from_file 5813ea38.0 -s init stop > {"init terminating in > do_boot",{{badmatch,{error,{asn1,{invalid_choice_tag,{17,[{16,[{6,<<3 > bytes>>},{19,<<4 > bytes>>}]}]}}}}},[{public_key,pkix_decode_cert,2,[{file,"public_key.er > bytes>>l"},{line,216}]},{test_cert,cert_from_file,1,[{file,"test_cert. > bytes>>erl"},{line,15}]},{init,start_it,1,[]},{init,start_em,1,[]}]}} > > Crash dump was written to: erl_crash.dump init terminating in do_boot > () > > > This certificate is handled ok by OpenSSL (e.g. openssl x509 -in > 5813ea38.0 -text -noout) and by at least one Java X.509 implementation. > > I haven't looked in to the process of how > public_key/asn1/OTP-PUB-KEY.erl is generated, but this block of code > in the dec_AuthorityKeyIdentifier(Tlv, > TagIn) function: > > %%------------------------------------------------- > %% attribute authorityCertIssuer(2) External OTP-PUB-KEY:GeneralNames > OPTIONAL > %%------------------------------------------------- > {Term2, Tlv3} = case Tlv2 of > [{131073, V2} | TempTlv3] -> > {dec_GeneralNames(V2, []), TempTlv3}; > _ -> {asn1_NOVALUE, Tlv2} > end, > > Is where the problem start showing up. For the above certificate, it > is passing this to dec_GeneralNames(Tlv, TagIn): > > Tlv: [{17,[{16,[{6,<<85,4,10>>},{19,<<"Auto">>}]}]}, > {17,[{16,[{6,<<85,4,11>>},{19,<<"FutureGridNimbus">>}]}]}, > {17,[{16,[{6,<<85,4,3>>},{19,<<"CA">>}]}]}] > TagIn: [] > > This doesn't look like what dec_GeneralNames() expects. It is close to > what > dec_Name() expects, though. > > There are perhaps 2 problems here. First, ({1310??, ???}, []) needs to > be passed to dec_GeneralNames() not just (???, []). Second, 131076 > should be associated with the above Tlv, not 131073. > > So, a hack of: > > %%------------------------------------------------- > %% attribute authorityCertIssuer(2) External OTP-PUB-KEY:GeneralNames > OPTIONAL > %%------------------------------------------------- > {Term2, Tlv3} = case Tlv2 of > [{131073, V2} | TempTlv3] -> > {dec_GeneralNames([{131076, {16, V2}}], []), > TempTlv3}; > _ -> {asn1_NOVALUE, Tlv2} > end, > > Works around the problem for this certificate. > > What I haven't dug in to is why asn1rt_ber_bin_v2__decode(B, nif) is > picking > 131073 instead of 131076 (see below). I don't really understand what > these numbers represent or where they are coming from so I'm not sure > if there is a problem with the code, or with this certificate. > However, from RFC 3280, it seems like it is valid to have a Name/RDN > (or any other GeneralName) as the authorityCertIssuer. Maybe there is > a restriction somewhere that I'm missing, though... > > > decode(Type, Data) > Type: 'AuthorityKeyIdentifier' > Data: > <<48,82,128,20,24,108,58,144,28,124,144,19,105,161,199,17,225,187,125, > > 255,122,178,251,182,161,55,49,13,48,11,6,3,85,4,10,19,4,65,117,116, > > 111,49,25,48,23,6,3,85,4,11,19,16,70,117,116,117,114,101,71,114,105, > > 100,78,105,109,98,117,115,49,11,48,9,6,3,85,4,3,19,2,67,65,130,1,0>> > element: {16, > [{131072, > <<24,108,58,144,28,124,144,19,105,161,199,17,225,187,125,255, > 122,178,251,182>>}, > {131073, > [{17,[{16,[{6,<<85,4,10>>},{19,<<"Auto">>}]}]}, > {17,[{16,[{6,<<85,4,11>>},{19,<<"FutureGridNimbus">>}]}]}, > {17,[{16,[{6,<<85,4,3>>},{19,<<"CA">>}]}]}]}, > {131074,<<0>>}]} > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From xazar.studio@REDACTED Thu Aug 16 14:00:38 2012 From: xazar.studio@REDACTED (][azar) Date: Thu, 16 Aug 2012 16:00:38 +0400 Subject: [erlang-bugs] dialyzer / typer issue. Message-ID: I've some code like this. -module(test). -export([test/1]). . -spec my_apply(Arg,fun((Arg) -> Result)) -> Result. my_apply(Arg,Fun) -> Fun(Arg). -spec my_fun(good) -> ok ; (bad) -> error. my_fun(good) -> ok; my_fun(bad) -> error. test(A) -> my_apply(A,fun my_fun/1). And i whan't Dialyzer valid the A param in test/1 function, but Typer generates this spec: -spec test(_) -> any(). But valid is -spec test(good) -> ok ; (bad) -> error. I don't whant to write spec for functions like test/1 each time i use my_apply/2. How to help the dialyzer with type inference? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.pamelard@REDACTED Fri Aug 17 14:34:26 2012 From: stephane.pamelard@REDACTED (Stephane Pamelard) Date: Fri, 17 Aug 2012 14:34:26 +0200 Subject: [erlang-bugs] Not documented parameter in runtime_tools application (R15B01) Message-ID: <502E3A52.2010609@myriadgroup.biz> Hi, Please find a possible minor issue in runtime_tools application starting process. As said in the documentation, no parameter is defined in this application. However, when starting a node referring this application, not documented parameter /ttb_autostart_module/ appears. This is due to the following lines in ttb_autostart:init/1 function. /init(no_args) -> case application:get_env(runtime_tools, ttb_autostart_module) of {ok, _} -> ok; undefined -> application:set_env(runtime_tools, ttb_autostart_module, ?DEF_AUTOSTART_MODULE) end, observer_backend:ttb_resume_trace(), %%As the process is not needed any more, it will shut itself down {ok, no_args, 10000}./ Regards, St?phane *** DISCLAIMER *** This message, including attachments, is intended solely for the addressee indicated in this message and is strictly confidential or otherwise privileged. If you are not the intended recipient (or responsible for delivery of the message to such person) : - (1) please immediately (i) notify the sender by reply email and (ii) delete this message and attachments, - (2) any use, copy or dissemination of this transmission is strictly prohibited. If you or your employer does not consent to Internet email messages of this kind, please advise Myriad Group AG by reply e-mail immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by Myriad Group AG unless otherwise indicated by an authorized representative independent of this message. From vances@REDACTED Sat Aug 18 10:02:35 2012 From: vances@REDACTED (Vance Shipley) Date: Sat, 18 Aug 2012 13:32:35 +0530 Subject: [erlang-bugs] Segmentation Fault Using ets:test_ms/2 Message-ID: <20120818080234.GE361@aluminum.wavenet.lk> Erlang R15B01 (erts-5.9.1) [source] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.1 (abort with ^G) 1> rd(test, {a, b, c = gb_sets:new()}). test 2> ets:test_ms(#test{}, [{#test{_='_'}, [], ['$_']}]). size_object: bad tag for 0x0 Abort trap: 6 -- -Vance From sverker.eriksson@REDACTED Mon Aug 20 18:03:13 2012 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 20 Aug 2012 18:03:13 +0200 Subject: [erlang-bugs] Segmentation Fault Using ets:test_ms/2 In-Reply-To: <20120818080234.GE361@aluminum.wavenet.lk> References: <20120818080234.GE361@aluminum.wavenet.lk> Message-ID: <50325FC1.2010904@erix.ericsson.se> Thanks for reporting, Vance. This bug is specific to ets:test_ms and should not affect other use of match specs. It was introduced in R14B02. This should do it while waiting for R15B02: diff --git a/erts/emulator/beam/erl_db_util.c b/erts/emulator/beam/erl_db_util.c index 1aa0cb4..42907e2 100644 --- a/erts/emulator/beam/erl_db_util.c +++ b/erts/emulator/beam/erl_db_util.c @@ -1233,7 +1233,7 @@ static Eterm erts_match_set_run_ets(Process *p, Binary *mpsp, Eterm ret; ret = db_prog_match(p, mpsp, args, NULL, NULL, num_args, - ERTS_PAM_CONTIGUOUS_TUPLE | ERTS_PAM_COPY_RESULT, + ERTS_PAM_COPY_RESULT, return_flags); #if defined(HARDDEBUG) if (is_non_value(ret)) { /Sverker, Erlang/OTP Vance Shipley wrote: > Erlang R15B01 (erts-5.9.1) [source] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.9.1 (abort with ^G) > 1> rd(test, {a, b, c = gb_sets:new()}). > test > 2> ets:test_ms(#test{}, [{#test{_='_'}, [], ['$_']}]). > size_object: bad tag for 0x0 > Abort trap: 6 > > From daniel@REDACTED Mon Aug 20 21:31:31 2012 From: daniel@REDACTED (Daniel Luna) Date: Mon, 20 Aug 2012 15:31:31 -0400 Subject: [erlang-bugs] Large binaries are truncated by term_to_binary Message-ID: We found an issue with term_to_binary when playing around a bit with creating large binaries. Now that machines start having more and more memory this issue might pop up more often. The size field is only 32 bits wide and will apparently wrap if the binary is large enough. The following examples crashed in various ways on a machine with 8Gb of memory, and "worked" (i.e. did not work as intended) on a machine with 16Gb. The problem boils down to <<>> =:= binary_to_term(term_to_binary(<<0:(1 bsl 35)>>)), is true. Cheers, Daniel Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:6:6] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.1 (abort with ^G) 1> term_to_binary(<<0:(1 bsl 0)>>). <<131,77,0,0,0,1,1,0>> 2> term_to_binary(<<0:(1 bsl 34)>>). <<131,109,128,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,...>> 3> term_to_binary(<<0:(1 bsl 35)>>). <<131,109,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,...>> 4> binary_to_term(term_to_binary(<<0:(1 bsl 35)>>)). <<>> 5> binary_to_term(term_to_binary(<<0:(1 bsl 35), 0>>)). <<0>> From daniel@REDACTED Tue Aug 21 21:32:46 2012 From: daniel@REDACTED (Daniel Luna) Date: Tue, 21 Aug 2012 15:32:46 -0400 Subject: [erlang-bugs] Crash in SSL In-Reply-To: <502A6890.5070908@erix.ericsson.se> References: <502A6890.5070908@erix.ericsson.se> Message-ID: I'm using Erlang R15B01. This bug was also present in R14. This problem is also present in a recent version of maint. Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:6:6] [async-threads:0] [kernel-poll:false] Eshell V5.9.1 (abort with ^G) 1> application:start(crypto). ok 2> application:start(public_key). ok 3> application:start(ssl). ok 4> ssl:connect("login.secureserver.net", 443, [], infinity). ** exception exit: {{{badmatch, {error, {asn1, {{case_clause,19}, [{'OTP-PUB-KEY', check_and_convert_restricted_string,5, [{file,"OTP-PUB-KEY.erl"}, {line,14122}]}, Cheers, Daniel On 14 August 2012 11:02, Ingela Anderton Andin wrote: > Hi! > > Which versions of the ssl application and Erlang/OTP are you running? > > Regards Ingela Erlang/OTP team - Ericsson AB > > Daniel Luna wrote: >> >> We are experiencing a crash in ssl when trying to establish >> connections to websites with seemingly valid ssl certificates. Going >> to the following domains in a normal web browser will give a green >> light. Trying to connect to them using ssl:connect gives a crash. >> This crash occurs even with verify_none turned on. >> >> Some example domains are www.farmbureaubank.com and login.secureserver.net >> >> ssl:connect is working in general which is shown by the google.com >> example. >> >> Cheers, >> >> Daniel >> >> 1> ssl:connect("google.com", 443, [], infinity). >> {ok,{sslsocket,new_ssl,<0.8447.0>}} >> 2> ssl:connect("login.secureserver.net", 443, [{verify, >> verify_none}], infinity). >> ** exception exit: {{{badmatch, >> {error, >> {asn1, >> {{case_clause,19}, >> [{'OTP-PUB-KEY', >> >> check_and_convert_restricted_string,5, >> [{file,"OTP-PUB-KEY.erl"}, >> {line,14122}]}, >> {'OTP-PUB-KEY',decode,2, >> >> [{file,"OTP-PUB-KEY.erl"},{line,493}]}, >> {pubkey_cert_records,transform,2, >> [{file,"pubkey_cert_records.erl"}, >> {line,60}]}, >> {lists,map,2, >> [{file,"lists.erl"},{line,1173}]}, >> {pubkey_cert_records,transform,2, >> [{file,"pubkey_cert_records.erl"}, >> {line,72}]}, >> {pubkey_cert_records,decode_tbs,1, >> [{file,"pubkey_cert_records.erl"}, >> {line,190}]}, >> {pubkey_cert_records,decode_cert,1, >> [{file,"pubkey_cert_records.erl"}, >> {line,40}]}, >> {public_key,pkix_decode_cert,2, >> [{file,"public_key.erl"}, >> {line,211}]}]}}}}, >> [{public_key,pkix_decode_cert,2, >> [{file,"public_key.erl"},{line,215}]}, >> {public_key,path_validation,2, >> [{file,"public_key.erl"},{line,605}]}, >> {ssl_handshake,certify,7, >> [{file,"ssl_handshake.erl"},{line,218}]}, >> {ssl_connection,certify,2, >> [{file,"ssl_connection.erl"},{line,514}]}, >> {ssl_connection,next_state,4, >> [{file,"ssl_connection.erl"},{line,1929}]}, >> >> {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,494}]}, >> {proc_lib,init_p_do_apply,3, >> [{file,"proc_lib.erl"},{line,227}]}]}, >> {gen_fsm,sync_send_all_state_event, >> [<0.8453.0>,start,infinity]}} >> in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line >> 240) >> in call from ssl_connection:sync_send_all_state_event/3 >> (ssl_connection.erl, line 1195) >> in call from ssl_connection:handshake/2 (ssl_connection.erl, line >> 167) >> in call from ssl_connection:start_fsm/8 (ssl_connection.erl, line >> 1037) >> in call from ssl_connection:connect/7 (ssl_connection.erl, line 139) >> 18:40:19.798 [error] gen_fsm <0.8453.0> in state certify terminated >> with reason: no match of right hand value >> >> {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} >> in public_key:pkix_decode_cert/2 line 215 >> 18:40:19.931 [error] CRASH REPORT Process <0.8453.0> with 0 neighbours >> exited with reason: no match of right hand value >> >> {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} >> in public_key:pkix_decode_cert/2 line 215 in gen_fsm:terminate/7 line >> 611 >> 18:40:19.970 [error] Supervisor ssl_connection_sup had child undefined >> started with {ssl_connection,start_link,undefined} at <0.8453.0> exit >> with reason no match of right hand value >> >> {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} >> in public_key:pkix_decode_cert/2 line 215 in context child_terminated >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > > From daniel@REDACTED Tue Aug 21 23:07:15 2012 From: daniel@REDACTED (Daniel Luna) Date: Tue, 21 Aug 2012 17:07:15 -0400 Subject: [erlang-bugs] Crash in SSL In-Reply-To: References: <502A6890.5070908@erix.ericsson.se> Message-ID: Running a recent version of Ubuntu. > uname -a Linux spawn 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux I retested from a fresh clone of maint and the bug is still present. Cheers, Daniel ps. Ingela, you don't seem to be on the whitelist for being allowed to post to the list. Your reply is not in the list archives. On 21 August 2012 15:32, Daniel Luna wrote: > I'm using Erlang R15B01. This bug was also present in R14. > > This problem is also present in a recent version of maint. > > Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:6:6] > [async-threads:0] [kernel-poll:false] > > Eshell V5.9.1 (abort with ^G) > 1> application:start(crypto). > ok > 2> application:start(public_key). > ok > 3> application:start(ssl). > ok > 4> ssl:connect("login.secureserver.net", 443, [], infinity). > ** exception exit: {{{badmatch, > {error, > {asn1, > {{case_clause,19}, > [{'OTP-PUB-KEY', > check_and_convert_restricted_string,5, > [{file,"OTP-PUB-KEY.erl"}, > {line,14122}]}, > > Cheers, > > Daniel > > > On 14 August 2012 11:02, Ingela Anderton Andin > wrote: >> Hi! >> >> Which versions of the ssl application and Erlang/OTP are you running? >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> Daniel Luna wrote: >>> >>> We are experiencing a crash in ssl when trying to establish >>> connections to websites with seemingly valid ssl certificates. Going >>> to the following domains in a normal web browser will give a green >>> light. Trying to connect to them using ssl:connect gives a crash. >>> This crash occurs even with verify_none turned on. >>> >>> Some example domains are www.farmbureaubank.com and login.secureserver.net >>> >>> ssl:connect is working in general which is shown by the google.com >>> example. >>> >>> Cheers, >>> >>> Daniel >>> >>> 1> ssl:connect("google.com", 443, [], infinity). >>> {ok,{sslsocket,new_ssl,<0.8447.0>}} >>> 2> ssl:connect("login.secureserver.net", 443, [{verify, >>> verify_none}], infinity). >>> ** exception exit: {{{badmatch, >>> {error, >>> {asn1, >>> {{case_clause,19}, >>> [{'OTP-PUB-KEY', >>> >>> check_and_convert_restricted_string,5, >>> [{file,"OTP-PUB-KEY.erl"}, >>> {line,14122}]}, >>> {'OTP-PUB-KEY',decode,2, >>> >>> [{file,"OTP-PUB-KEY.erl"},{line,493}]}, >>> {pubkey_cert_records,transform,2, >>> [{file,"pubkey_cert_records.erl"}, >>> {line,60}]}, >>> {lists,map,2, >>> [{file,"lists.erl"},{line,1173}]}, >>> {pubkey_cert_records,transform,2, >>> [{file,"pubkey_cert_records.erl"}, >>> {line,72}]}, >>> {pubkey_cert_records,decode_tbs,1, >>> [{file,"pubkey_cert_records.erl"}, >>> {line,190}]}, >>> {pubkey_cert_records,decode_cert,1, >>> [{file,"pubkey_cert_records.erl"}, >>> {line,40}]}, >>> {public_key,pkix_decode_cert,2, >>> [{file,"public_key.erl"}, >>> {line,211}]}]}}}}, >>> [{public_key,pkix_decode_cert,2, >>> [{file,"public_key.erl"},{line,215}]}, >>> {public_key,path_validation,2, >>> [{file,"public_key.erl"},{line,605}]}, >>> {ssl_handshake,certify,7, >>> [{file,"ssl_handshake.erl"},{line,218}]}, >>> {ssl_connection,certify,2, >>> [{file,"ssl_connection.erl"},{line,514}]}, >>> {ssl_connection,next_state,4, >>> [{file,"ssl_connection.erl"},{line,1929}]}, >>> >>> {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,494}]}, >>> {proc_lib,init_p_do_apply,3, >>> [{file,"proc_lib.erl"},{line,227}]}]}, >>> {gen_fsm,sync_send_all_state_event, >>> [<0.8453.0>,start,infinity]}} >>> in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line >>> 240) >>> in call from ssl_connection:sync_send_all_state_event/3 >>> (ssl_connection.erl, line 1195) >>> in call from ssl_connection:handshake/2 (ssl_connection.erl, line >>> 167) >>> in call from ssl_connection:start_fsm/8 (ssl_connection.erl, line >>> 1037) >>> in call from ssl_connection:connect/7 (ssl_connection.erl, line 139) >>> 18:40:19.798 [error] gen_fsm <0.8453.0> in state certify terminated >>> with reason: no match of right hand value >>> >>> {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} >>> in public_key:pkix_decode_cert/2 line 215 >>> 18:40:19.931 [error] CRASH REPORT Process <0.8453.0> with 0 neighbours >>> exited with reason: no match of right hand value >>> >>> {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} >>> in public_key:pkix_decode_cert/2 line 215 in gen_fsm:terminate/7 line >>> 611 >>> 18:40:19.970 [error] Supervisor ssl_connection_sup had child undefined >>> started with {ssl_connection,start_link,undefined} at <0.8453.0> exit >>> with reason no match of right hand value >>> >>> {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} >>> in public_key:pkix_decode_cert/2 line 215 in context child_terminated >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >>> >> >> From kenneth.lundin@REDACTED Wed Aug 22 08:57:58 2012 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 22 Aug 2012 08:57:58 +0200 Subject: [erlang-bugs] Crash in SSL In-Reply-To: References: Message-ID: Hi Daniel, We have looked into this and found that the certificate from Farmbureaubank is incorrect with respect to the standard. The countryname "US" is supposed to be of type printablestring but is encoded as utf8string in one instance of countryname out of two in this certificate. The crasch is a bug in that a proper error indicating wrong tag in input data shoul have been returned instead. The explanation to why this certificate is accepted by other ssl implementations is that they don't check or don,t care about the stringtype for countryname. When searching on the net for similar problems I found that e.g Netscape also seems to crasch on the same input. We are thinking of adding a more forgiving when decoding of parts of the data in a certificate in order to be compatible with openssl and other implementations. We strongly suspect that the certificate in question is created with openssl and that it depends on certain settings regarding stringtypes in openssl.cnf. When time allows we will verify that. /Kenneth, Erlang/OTP Ericsson Den 9 aug 2012 00:43 skrev "Daniel Luna" : > We are experiencing a crash in ssl when trying to establish > connections to websites with seemingly valid ssl certificates. Going > to the following domains in a normal web browser will give a green > light. Trying to connect to them using ssl:connect gives a crash. > This crash occurs even with verify_none turned on. > > Some example domains are www.farmbureaubank.com and login.secureserver.net > > ssl:connect is working in general which is shown by the google.comexample. > > Cheers, > > Daniel > > 1> ssl:connect("google.com", 443, [], infinity). > {ok,{sslsocket,new_ssl,<0.8447.0>}} > 2> ssl:connect("login.secureserver.net", 443, [{verify, > verify_none}], infinity). > ** exception exit: {{{badmatch, > {error, > {asn1, > {{case_clause,19}, > [{'OTP-PUB-KEY', > > check_and_convert_restricted_string,5, > [{file,"OTP-PUB-KEY.erl"}, > {line,14122}]}, > {'OTP-PUB-KEY',decode,2, > > [{file,"OTP-PUB-KEY.erl"},{line,493}]}, > {pubkey_cert_records,transform,2, > [{file,"pubkey_cert_records.erl"}, > {line,60}]}, > {lists,map,2, > [{file,"lists.erl"},{line,1173}]}, > {pubkey_cert_records,transform,2, > [{file,"pubkey_cert_records.erl"}, > {line,72}]}, > {pubkey_cert_records,decode_tbs,1, > [{file,"pubkey_cert_records.erl"}, > {line,190}]}, > {pubkey_cert_records,decode_cert,1, > [{file,"pubkey_cert_records.erl"}, > {line,40}]}, > {public_key,pkix_decode_cert,2, > [{file,"public_key.erl"}, > {line,211}]}]}}}}, > [{public_key,pkix_decode_cert,2, > [{file,"public_key.erl"},{line,215}]}, > {public_key,path_validation,2, > [{file,"public_key.erl"},{line,605}]}, > {ssl_handshake,certify,7, > [{file,"ssl_handshake.erl"},{line,218}]}, > {ssl_connection,certify,2, > [{file,"ssl_connection.erl"},{line,514}]}, > {ssl_connection,next_state,4, > [{file,"ssl_connection.erl"},{line,1929}]}, > > {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,494}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,227}]}]}, > {gen_fsm,sync_send_all_state_event, > [<0.8453.0>,start,infinity]}} > in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line > 240) > in call from ssl_connection:sync_send_all_state_event/3 > (ssl_connection.erl, line 1195) > in call from ssl_connection:handshake/2 (ssl_connection.erl, line 167) > in call from ssl_connection:start_fsm/8 (ssl_connection.erl, line > 1037) > in call from ssl_connection:connect/7 (ssl_connection.erl, line 139) > 18:40:19.798 [error] gen_fsm <0.8453.0> in state certify terminated > with reason: no match of right hand value > > {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} > in public_key:pkix_decode_cert/2 line 215 > 18:40:19.931 [error] CRASH REPORT Process <0.8453.0> with 0 neighbours > exited with reason: no match of right hand value > > {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} > in public_key:pkix_decode_cert/2 line 215 in gen_fsm:terminate/7 line > 611 > 18:40:19.970 [error] Supervisor ssl_connection_sup had child undefined > started with {ssl_connection,start_link,undefined} at <0.8453.0> exit > with reason no match of right hand value > > {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} > in public_key:pkix_decode_cert/2 line 215 in context child_terminated > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Wed Aug 22 11:07:06 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 22 Aug 2012 11:07:06 +0200 Subject: [erlang-bugs] flag documentation bugs in erts/erl Message-ID: <5034A13A.5070503@gmail.com> http://www.erlang.org/doc/man/erl.html +P Number Sets the maximum number of concurrent processes for this system. Number must be in the range 16..134217727. Default is 32768. As far as I can tell, the lower limit is 256, not 16, and the default seems to be higher these days. +e Number Set max number of ETS tables. This flag doesn't seem to actually exist. /Richard From jonas.falkevik@REDACTED Wed Aug 22 12:05:27 2012 From: jonas.falkevik@REDACTED (Jonas Falkevik) Date: Wed, 22 Aug 2012 12:05:27 +0200 Subject: [erlang-bugs] flag documentation bugs in erts/erl In-Reply-To: <5034A13A.5070503@gmail.com> References: <5034A13A.5070503@gmail.com> Message-ID: I think it is there, but should be +eNumber. Number bigger than default 2053. case 'e': if (sys_strcmp("c", argv[i]+2) == 0) { erts_ets_always_compress = 1; } else { /* set maximum number of ets tables */ arg = get_arg(argv[i]+2, argv[i+1], &i); if (( user_requested_db_max_tabs = atoi(arg) ) < 0) { erts_fprintf(stderr, "bad maximum number of ets tables %s\n", arg); erts_usage(); } VERBOSE(DEBUG_SYSTEM, ("using maximum number of ets tables %d\n", user_requested_db_max_tabs)); } break; /Jonas On Aug 22, 2012, at 11:07 , Richard Carlsson wrote: > http://www.erlang.org/doc/man/erl.html > > +P Number > Sets the maximum number of concurrent processes for this system. > Number must be in the range 16..134217727. Default is 32768. > > As far as I can tell, the lower limit is 256, not 16, and the default seems to be higher these days. > > +e Number > Set max number of ETS tables. > > This flag doesn't seem to actually exist. > > /Richard > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From carlsson.richard@REDACTED Wed Aug 22 12:09:30 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 22 Aug 2012 12:09:30 +0200 Subject: [erlang-bugs] Obsolete FAQ entry Message-ID: <5034AFDA.40300@gmail.com> http://www.erlang.org/faq/how_do_i.html#id52968 "How do I find out which line my Erlang program crashed at?" can be removed from the faq as of R15. /Richard From hans.bolinder@REDACTED Wed Aug 22 12:25:01 2012 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Wed, 22 Aug 2012 12:25:01 +0200 Subject: [erlang-bugs] Non-ASCII xref paths fail In-Reply-To: <50259823.1090502@rabbitmq.com> References: <50259823.1090502@rabbitmq.com> Message-ID: <20532.45949.159951.922598@ornendil.otp.ericsson.se> Hi, > xref_utils:is_string/2 enforces the overly conservative upper limit of > 126 in character codes. We'll include a simple fix in the upcoming R15B02. Thanks. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From matthias@REDACTED Wed Aug 22 14:24:04 2012 From: matthias@REDACTED (Matthias Lang) Date: Wed, 22 Aug 2012 14:24:04 +0200 Subject: [erlang-bugs] Obsolete FAQ entry In-Reply-To: <5034AFDA.40300@gmail.com> References: <5034AFDA.40300@gmail.com> Message-ID: <20120822122404.GA16050@corelatus.se> On Wednesday, August 22, Richard Carlsson wrote: > http://www.erlang.org/faq/how_do_i.html#id52968 > > "How do I find out which line my Erlang program crashed at?" can be > removed from the faq as of R15. Thanks for catching that, I've removed it. BTW: the FAQ source is in git, at https://github.com/matthiasl/Erlang-FAQ and I even get the odd surprise patch from someone I've never heard of before. Matthias From daniel@REDACTED Wed Aug 22 16:33:03 2012 From: daniel@REDACTED (Daniel Luna) Date: Wed, 22 Aug 2012 10:33:03 -0400 Subject: [erlang-bugs] Crash in SSL In-Reply-To: References: Message-ID: Hi Kenneth, Long time, no see. So to me it looks like this is a combination of issues. It would make me very happy if the OTP team could state the intention to fix these issues in the near future. 1. The Erlang ssl module verifies the validity of the certificate even when {verify, verify_none} has been set. This could most easily be fixed by a change to the documentation about what it means to use the verify_none verification. 2. The ssl module *crashes* on bad data instead of returning {error, Error} or {ok, Conn} (note that this crash happens for {verify, verify_none} which should give us a connection back even if the certificate is bad) 3. A gen_fsm dies in the background (with the main issue of clobbering our error logs, and hiding real errors behind all the noise) 4. The Erlang ssl module is in disagreement with Chrome and Firefox (and probably other browsers) about what is a valid certificate 1, 2, and 3 are definitely bugs. I personally think 4 is a bug too, but am willing to listen to arguments stating otherwise. (As a side note I don't see how the utf8-encoded string "US" is in any way bitwise different from the ASCII-encoded string "US" and I don't manage to find out if there is a type tag somewhere) Cheers, Daniel On 22 August 2012 02:57, Kenneth Lundin wrote: > Hi Daniel, > > We have looked into this and found that the certificate from Farmbureaubank > is incorrect with respect to the standard. > The countryname "US" is supposed to be of type printablestring but is > encoded as utf8string in one instance of countryname out of two in this > certificate. > > The crasch is a bug in that a proper error indicating wrong tag in input > data shoul have been returned instead. > > The explanation to why this certificate is accepted by other ssl > implementations is that they don't check or don,t care about the stringtype > for countryname. > > When searching on the net for similar problems I found that e.g Netscape > also seems to crasch on the same input. > > We are thinking of adding a more forgiving when decoding of parts of the > data in a certificate in order to be compatible with openssl and other > implementations. > > We strongly suspect that the certificate in question is created with openssl > and that it depends on certain settings regarding stringtypes in > openssl.cnf. > When time allows we will verify that. > > /Kenneth, Erlang/OTP Ericsson > > Den 9 aug 2012 00:43 skrev "Daniel Luna" : >> >> We are experiencing a crash in ssl when trying to establish >> connections to websites with seemingly valid ssl certificates. Going >> to the following domains in a normal web browser will give a green >> light. Trying to connect to them using ssl:connect gives a crash. >> This crash occurs even with verify_none turned on. >> >> Some example domains are www.farmbureaubank.com and login.secureserver.net >> >> ssl:connect is working in general which is shown by the google.com >> example. >> >> Cheers, >> >> Daniel >> >> 1> ssl:connect("google.com", 443, [], infinity). >> {ok,{sslsocket,new_ssl,<0.8447.0>}} >> 2> ssl:connect("login.secureserver.net", 443, [{verify, >> verify_none}], infinity). >> ** exception exit: {{{badmatch, >> {error, >> {asn1, >> {{case_clause,19}, >> [{'OTP-PUB-KEY', >> >> check_and_convert_restricted_string,5, >> [{file,"OTP-PUB-KEY.erl"}, >> {line,14122}]}, >> {'OTP-PUB-KEY',decode,2, >> >> [{file,"OTP-PUB-KEY.erl"},{line,493}]}, >> {pubkey_cert_records,transform,2, >> [{file,"pubkey_cert_records.erl"}, >> {line,60}]}, >> {lists,map,2, >> [{file,"lists.erl"},{line,1173}]}, >> {pubkey_cert_records,transform,2, >> [{file,"pubkey_cert_records.erl"}, >> {line,72}]}, >> {pubkey_cert_records,decode_tbs,1, >> [{file,"pubkey_cert_records.erl"}, >> {line,190}]}, >> {pubkey_cert_records,decode_cert,1, >> [{file,"pubkey_cert_records.erl"}, >> {line,40}]}, >> {public_key,pkix_decode_cert,2, >> [{file,"public_key.erl"}, >> {line,211}]}]}}}}, >> [{public_key,pkix_decode_cert,2, >> [{file,"public_key.erl"},{line,215}]}, >> {public_key,path_validation,2, >> [{file,"public_key.erl"},{line,605}]}, >> {ssl_handshake,certify,7, >> [{file,"ssl_handshake.erl"},{line,218}]}, >> {ssl_connection,certify,2, >> [{file,"ssl_connection.erl"},{line,514}]}, >> {ssl_connection,next_state,4, >> [{file,"ssl_connection.erl"},{line,1929}]}, >> >> {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,494}]}, >> {proc_lib,init_p_do_apply,3, >> [{file,"proc_lib.erl"},{line,227}]}]}, >> {gen_fsm,sync_send_all_state_event, >> [<0.8453.0>,start,infinity]}} >> in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line >> 240) >> in call from ssl_connection:sync_send_all_state_event/3 >> (ssl_connection.erl, line 1195) >> in call from ssl_connection:handshake/2 (ssl_connection.erl, line >> 167) >> in call from ssl_connection:start_fsm/8 (ssl_connection.erl, line >> 1037) >> in call from ssl_connection:connect/7 (ssl_connection.erl, line 139) >> 18:40:19.798 [error] gen_fsm <0.8453.0> in state certify terminated >> with reason: no match of right hand value >> >> {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} >> in public_key:pkix_decode_cert/2 line 215 >> 18:40:19.931 [error] CRASH REPORT Process <0.8453.0> with 0 neighbours >> exited with reason: no match of right hand value >> >> {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} >> in public_key:pkix_decode_cert/2 line 215 in gen_fsm:terminate/7 line >> 611 >> 18:40:19.970 [error] Supervisor ssl_connection_sup had child undefined >> started with {ssl_connection,start_link,undefined} at <0.8453.0> exit >> with reason no match of right hand value >> >> {error,{asn1,{{case_clause,19},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14122}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,493}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,190}]},{pubkey_cert_records,...},...]}}} >> in public_key:pkix_decode_cert/2 line 215 in context child_terminated >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From ingela.anderton.andin@REDACTED Thu Aug 23 12:11:48 2012 From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin) Date: Thu, 23 Aug 2012 12:11:48 +0200 Subject: [erlang-bugs] Crash in SSL In-Reply-To: <5035F7C0.2030402@erix.ericsson.se> References: <5035F7C0.2030402@erix.ericsson.se> Message-ID: <503601E4.9070908@erix.ericsson.se> Hi! Daniel Luna wrote: > Hi Kenneth, > > Long time, no see. > > So to me it looks like this is a combination of issues. It would make > me very happy if the OTP team could state the intention to fix these > issues in the near future. > We will do something about it in a near future. > 1. The Erlang ssl module verifies the validity of the certificate even > when {verify, verify_none} has been set. This could most easily be > fixed by a change to the documentation about what it means to use the > verify_none verification. > > It does not verify the validity of the certificate in verify_none mode, it however unpacks (decodes) the certificate using the ASN-1 spec, we still need to go through the certificate path to extract the public key. The thing that happens is that your certificate for some reason violates the ASN-1 spec, however in practice the value is an allowed one and we could make a workaround to allow it. > 2. The ssl module *crashes* on bad data instead of returning {error > Error} or {ok, Conn} (note that this crash happens for {verify, > verify_none} which should give us a connection back even if the > certificate is bad) > It would have if there had been a certificate path validation error, e.i. that the certificate was bad in that sense. Your certificate is not on the correct format for a certificate and that is the problem. > 3. A gen_fsm dies in the background (with the main issue of clobbering > our error logs, and hiding real errors behind all the noise) > > I agree that we could make it go down gracefully if the certificate can not be decoded, we will fix that. > 4. The Erlang ssl module is in disagreement with Chrome and Firefox > (and probably other browsers) about what is a valid certificate > > 1, 2, and 3 are definitely bugs. I personally think 4 is a bug too, > but am willing to listen to arguments stating otherwise. > (As a side note I don't see how the utf8-encoded string "US" is in > any way bitwise different from the ASCII-encoded string "US" and I don't > manage to find out if there is a type tag somewhere) > That other implementations relax the spec requirements intentionally or unintentionally does not make your certificate correct, however we think that we need to be practical about this and make a workaround so that we accept such certificates as they are conceptually correct (and accepted by other big players) but technically wrong. Regards Ingela Erlang/OTP team - Ericsson AB From carlsson.richard@REDACTED Sat Aug 25 21:39:05 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sat, 25 Aug 2012 21:39:05 +0200 Subject: [erlang-bugs] heart prevents beam from creating crash dumps Message-ID: <503929D9.6000003@gmail.com> We have had a long-standing problems with not getting any Erlang crash dumps at all on our live servers. I finally figured out why it happens. I have already reported this to the OTP folks, but I thought I should send a summary to the mailing lists for documentation and to give people a heads-up. The problem occurs when you start Erlang with the -heart flag (http://www.erlang.org/doc/man/heart.html). This spawns a small external C program connected through a port. From Erlang's point of view it's like any other port program. The heart program pings the Erlang side every now and then, and if it gets no reply within HEART_BEAT_TIMEOUT seconds, or if the connection to Erlang breaks, it assumes the Beam process has gone bad and kills it off with a SIGKILL, and then restarts Erlang using whatever HEART_COMMAND is set to. So far so good. Normally, when Beam detects a critical situation (e.g., out of memory) and decides to shut down, it will create an erl_crash.dump file (or whatever ERL_CRASH_DUMP is set to). This information can greatly help figuring out what went wrong. But if the system that crashed was large, the crash dump file can take quite a long time to create. In order to make it possible to restart the node (reusing the node name) while the old defunct system is still writing the crash dump, Beam wants to drop its connection to the EPMD service before it starts writing the dump, making it look like the old node has disappeared. The code that does this is the function prepare_crash_dump() in erts/emulator/sys/unix/sys.c. The problem from the perspective of the C code is that the connection to EPMD is on some unknown file descriptor (just like heart, this has been started as a port from Erlang code). The solution they chose, and which has been part of the OTP system for years, is to close _all_ file descriptors except 0-2. This certainly has the desired effect that EPMD releases the node name for reuse. But it also, when the loop gets to file descriptor 10 or thereabouts (probably depending on your system), has the effect of breaking the connection to the heart program. In these multicore days, the effect is almost instantaneous. The heart program immediately wakes up due to the broken pipe and sends SIGKILL to Beam for good measure, to make sure it's really gone, and then it starts a new Erlang node. Meanwhile, the old node is still busy closing file descriptors. Sometimes it makes it as far as 12 before SIGKILL arrives. The poor thing never has a chance to even open the crash dump file for writing. And your operations people only see a weird restart without any further clues. I don't have a good solution right now, except "don't use -heart". And it might be that one wants to separate the automatic restarting of a crashed node from the automatic killing of an unresponsive node anyway. Suggestions are welcome. /Richard From vinoski@REDACTED Sat Aug 25 21:48:42 2012 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 25 Aug 2012 15:48:42 -0400 Subject: [erlang-bugs] heart prevents beam from creating crash dumps In-Reply-To: <503929D9.6000003@gmail.com> References: <503929D9.6000003@gmail.com> Message-ID: On Sat, Aug 25, 2012 at 3:39 PM, Richard Carlsson wrote: > We have had a long-standing problems with not getting any Erlang crash dumps > at all on our live servers. I finally figured out why it happens. I have > already reported this to the OTP folks, but I thought I should send a > summary to the mailing lists for documentation and to give people a > heads-up. > > The problem occurs when you start Erlang with the -heart flag > (http://www.erlang.org/doc/man/heart.html). This spawns a small external C > program connected through a port. From Erlang's point of view it's like any > other port program. The heart program pings the Erlang side every now and > then, and if it gets no reply within HEART_BEAT_TIMEOUT seconds, or if the > connection to Erlang breaks, it assumes the Beam process has gone bad and > kills it off with a SIGKILL, and then restarts Erlang using whatever > HEART_COMMAND is set to. So far so good. > > Normally, when Beam detects a critical situation (e.g., out of memory) and > decides to shut down, it will create an erl_crash.dump file (or whatever > ERL_CRASH_DUMP is set to). This information can greatly help figuring out > what went wrong. But if the system that crashed was large, the crash dump > file can take quite a long time to create. In order to make it possible to > restart the node (reusing the node name) while the old defunct system is > still writing the crash dump, Beam wants to drop its connection to the EPMD > service before it starts writing the dump, making it look like the old node > has disappeared. > > The code that does this is the function prepare_crash_dump() in > erts/emulator/sys/unix/sys.c. The problem from the perspective of the C code > is that the connection to EPMD is on some unknown file descriptor (just like > heart, this has been started as a port from Erlang code). The solution they > chose, and which has been part of the OTP system for years, is to close > _all_ file descriptors except 0-2. This certainly has the desired effect > that EPMD releases the node name for reuse. But it also, when the loop gets > to file descriptor 10 or thereabouts (probably depending on your system), > has the effect of breaking the connection to the heart program. > > In these multicore days, the effect is almost instantaneous. The heart > program immediately wakes up due to the broken pipe and sends SIGKILL to > Beam for good measure, to make sure it's really gone, and then it starts a > new Erlang node. Meanwhile, the old node is still busy closing file > descriptors. Sometimes it makes it as far as 12 before SIGKILL arrives. The > poor thing never has a chance to even open the crash dump file for writing. > And your operations people only see a weird restart without any further > clues. > > I don't have a good solution right now, except "don't use -heart". And it > might be that one wants to separate the automatic restarting of a crashed > node from the automatic killing of an unresponsive node anyway. Suggestions > are welcome. Hi Richard, I hit this problem a few years ago. Here's the thread starting from where I posted a temporary solution: http://erlang.org/pipermail/erlang-questions/2010-August/052970.html Unfortunately no patches came out of that conversation, but Ulf had an idea that might be worth exploring in a followup to the post linked above. --steve From carlsson.richard@REDACTED Sat Aug 25 22:03:02 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sat, 25 Aug 2012 22:03:02 +0200 Subject: [erlang-bugs] heart prevents beam from creating crash dumps In-Reply-To: References: <503929D9.6000003@gmail.com> Message-ID: <50392F76.4020501@gmail.com> On 08/25/2012 09:48 PM, Steve Vinoski wrote: > On Sat, Aug 25, 2012 at 3:39 PM, Richard Carlsson > wrote: >> We have had a long-standing problems with not getting any Erlang crash dumps >> at all on our live servers. I finally figured out why it happens. I have >> already reported this to the OTP folks, but I thought I should send a >> summary to the mailing lists for documentation and to give people a >> heads-up. >> >> The problem occurs when you start Erlang with the -heart flag >> (http://www.erlang.org/doc/man/heart.html). This spawns a small external C >> program connected through a port. From Erlang's point of view it's like any >> other port program. The heart program pings the Erlang side every now and >> then, and if it gets no reply within HEART_BEAT_TIMEOUT seconds, or if the >> connection to Erlang breaks, it assumes the Beam process has gone bad and >> kills it off with a SIGKILL, and then restarts Erlang using whatever >> HEART_COMMAND is set to. So far so good. >> >> Normally, when Beam detects a critical situation (e.g., out of memory) and >> decides to shut down, it will create an erl_crash.dump file (or whatever >> ERL_CRASH_DUMP is set to). This information can greatly help figuring out >> what went wrong. But if the system that crashed was large, the crash dump >> file can take quite a long time to create. In order to make it possible to >> restart the node (reusing the node name) while the old defunct system is >> still writing the crash dump, Beam wants to drop its connection to the EPMD >> service before it starts writing the dump, making it look like the old node >> has disappeared. >> >> The code that does this is the function prepare_crash_dump() in >> erts/emulator/sys/unix/sys.c. The problem from the perspective of the C code >> is that the connection to EPMD is on some unknown file descriptor (just like >> heart, this has been started as a port from Erlang code). The solution they >> chose, and which has been part of the OTP system for years, is to close >> _all_ file descriptors except 0-2. This certainly has the desired effect >> that EPMD releases the node name for reuse. But it also, when the loop gets >> to file descriptor 10 or thereabouts (probably depending on your system), >> has the effect of breaking the connection to the heart program. >> >> In these multicore days, the effect is almost instantaneous. The heart >> program immediately wakes up due to the broken pipe and sends SIGKILL to >> Beam for good measure, to make sure it's really gone, and then it starts a >> new Erlang node. Meanwhile, the old node is still busy closing file >> descriptors. Sometimes it makes it as far as 12 before SIGKILL arrives. The >> poor thing never has a chance to even open the crash dump file for writing. >> And your operations people only see a weird restart without any further >> clues. >> >> I don't have a good solution right now, except "don't use -heart". And it >> might be that one wants to separate the automatic restarting of a crashed >> node from the automatic killing of an unresponsive node anyway. Suggestions >> are welcome. > > Hi Richard, I hit this problem a few years ago. Here's the thread > starting from where I posted a temporary solution: > > http://erlang.org/pipermail/erlang-questions/2010-August/052970.html Yes, I had seen that. (It was pretty much the only thing that Google came up with for this particular topic.) But the key point that was missing from that discussion was that it ironically enough is the act of preparing to write a crash dump that ends up killing the system before it can write the crash dump. It would be great if there was a way of simply figuring out the file descriptor numbers used for EPMD and/or heart from the C code. Then it would be easy to fix this. One possibility is to add a new BIF that stores the current EPMD port in a C variable. Then the loop that closes all ports could be replaced with a single close. /Richard From pguyot@REDACTED Mon Aug 27 10:16:34 2012 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 27 Aug 2012 10:16:34 +0200 Subject: [erlang-bugs] heart prevents beam from creating crash dumps In-Reply-To: References: Message-ID: > It would be great if there was a way of simply figuring out the file > descriptor numbers used for EPMD and/or heart from the C code. Then it > would be easy to fix this. One possibility is to add a new BIF that > stores the current EPMD port in a C variable. Then the loop that closes > all ports could be replaced with a single close. I would like to strongly argue against a selected close of the epmd port. The main argument is that it singles out the node name as the only exclusive resource a node can have. Other resources cannot be shared between incarnations of the same node. For example, a node may open a pool of N connections to a database server which could be limited, by configuration, to a total count of M connections where M < 2 * N. Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From ulf@REDACTED Mon Aug 27 10:30:55 2012 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 27 Aug 2012 10:30:55 +0200 Subject: [erlang-bugs] heart prevents beam from creating crash dumps In-Reply-To: References: Message-ID: <17569384-D457-46F8-BC26-00E7B5CD238C@feuerlabs.com> So the suggestion then would be to selectively close everything *but* the heart fd? :) BR, Ulf W On 27 Aug 2012, at 10:16, Paul Guyot wrote: >> It would be great if there was a way of simply figuring out the file >> descriptor numbers used for EPMD and/or heart from the C code. Then it >> would be easy to fix this. One possibility is to add a new BIF that >> stores the current EPMD port in a C variable. Then the loop that closes >> all ports could be replaced with a single close. > > I would like to strongly argue against a selected close of the epmd port. > > The main argument is that it singles out the node name as the only exclusive resource a node can have. Other resources cannot be shared between incarnations of the same node. For example, a node may open a pool of N connections to a database server which could be limited, by configuration, to a total count of M connections where M < 2 * N. > > Paul > -- > Semiocast http://semiocast.com/ > +33.183627948 - 20 rue Lacaze, 75014 Paris > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From ess@REDACTED Mon Aug 27 10:37:00 2012 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 27 Aug 2012 10:37:00 +0200 Subject: [erlang-bugs] heart prevents beam from creating crash dumps In-Reply-To: References: Message-ID: <503B31AC.3010800@trifork.com> On 27-08-2012 10:16, Paul Guyot wrote: >> It would be great if there was a way of simply figuring out the file >> descriptor numbers used for EPMD and/or heart from the C code. Then it >> would be easy to fix this. One possibility is to add a new BIF that >> stores the current EPMD port in a C variable. Then the loop that closes >> all ports could be replaced with a single close. > I would like to strongly argue against a selected close of the epmd port. > > The main argument is that it singles out the node name as the only exclusive resource a node can have. I was thinking the same thing, but about listening sockets. It'd probably make better sense to make the heart FD be the special case, like stdin/out/err are already. Alternatively, could the node communicate to heart that it is dumping, so that heart can leave it be (at least for a while)? That would of course also make the FD special, so probably no gain. Is kill-on-close the right behaviour for heart? The "if the connection to Erlang breaks, it assumes the Beam process has gone bad" reaction, is it justified? That could be changed to "if the connection breaks, then assume - at least for a while - that the Beam process is going down." If, after a timeout after the connection disappeared, the Beam process is still around (or, possibly, that heart observes no growth in the dump file... don't know if that's too much complexity), *then* go assume badness and go for the kill. For great justice. 2? /Erik > Other resources cannot be shared between incarnations of the same node. For example, a node may open a pool of N connections to a database server which could be limited, by configuration, to a total count of M connections where M < 2 * N. > > Paul -- Mobile: + 45 26 36 17 55 | Skype: eriksoesorensen | Twitter: @eriksoe Trifork A/S | Margrethepladsen 4 | DK-8000 Aarhus C | www.trifork.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pguyot@REDACTED Mon Aug 27 12:22:59 2012 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 27 Aug 2012 12:22:59 +0200 Subject: [erlang-bugs] heart prevents beam from creating crash dumps In-Reply-To: References: Message-ID: <234F0FB0-1C67-4008-B7E4-EDFBFA53054A@kallisys.net> > On 27-08-2012 10:16, Paul Guyot wrote: >>> It would be great if there was a way of simply figuring out the file >>> descriptor numbers used for EPMD and/or heart from the C code. Then it >>> would be easy to fix this. One possibility is to add a new BIF that >>> stores the current EPMD port in a C variable. Then the loop that closes >>> all ports could be replaced with a single close. >> I would like to strongly argue against a selected close of the epmd port. >> >> The main argument is that it singles out the node name as the only exclusive resource a node can have. > I was thinking the same thing, but about listening sockets. > It'd probably make better sense to make the heart FD be the special > case, like stdin/out/err are already. > > Alternatively, could the node communicate to heart that it is dumping, > so that heart can leave it be (at least for a while)? That would of > course also make the FD special, so probably no gain. > > Is kill-on-close the right behaviour for heart? The "if the connection > to Erlang breaks, it assumes the Beam process has gone bad" reaction, is > it justified? That could be changed to "if the connection breaks, then > assume - at least for a while - that the Beam process is going down." > If, after a timeout after the connection disappeared, the Beam process > is still around (or, possibly, that heart observes no growth in the dump > file... don't know if that's too much complexity), *then* go assume > badness and go for the kill. For great justice. Altering the protocol makes sense as heart will kill the beam process if it did not get a beat for a given period (60 seconds by default). When the VM is crashing, no erlang code is running and therefore no beat signal is ever sent again to heart. I would not be surprised that preparing a dump and writing it to disk can typically take more than 30 seconds. Communication between heart and the VM lies in several channels. As an alternative to altering the protocol on the heart socket, we could change the signals heart sends to the VM (currently a SIGKILL every second for 5 seconds), although this would not be compatible with Windows' version of heart or custom heart commands. Alternatively, the VM could fork on exit, with both processes closing all files (after the fork, to make sure heart does not kill the parent beforehand) and the child writing the dump. I am not sure how this would transpose on Windows, though. Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From jonas.boberg@REDACTED Mon Aug 27 12:36:51 2012 From: jonas.boberg@REDACTED (Jonas Boberg) Date: Mon, 27 Aug 2012 12:36:51 +0200 Subject: [erlang-bugs] heart prevents beam from creating crash dumps In-Reply-To: <234F0FB0-1C67-4008-B7E4-EDFBFA53054A@kallisys.net> References: <234F0FB0-1C67-4008-B7E4-EDFBFA53054A@kallisys.net> Message-ID: > I would not be surprised that preparing a dump and writing it to disk can typically take more than 30 seconds. Definitely. On systems with lots of RAM (48 GB in this case), writing the crash dump takes several minutes. Ideally the heart behavior should be configurable. Normally we don't want to wait several minutes for heart to kill the node, so that it comes back up. Sometimes when investigating a production crash though, we would like to configure heart to wait for the crash dump to be written. From daniel.goertzen@REDACTED Mon Aug 27 20:08:04 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 27 Aug 2012 13:08:04 -0500 Subject: [erlang-bugs] crash dump on large ssh:connection_send() Message-ID: When I try to send a large binary (13 MB) through an SSH channel using "ssh:connection_send()", my VM freezes with a CPU pinned and I am forced to kill it. One time it managed to get this message out: Crash dump was written to: erl_crash.dump eheap_alloc: Cannot allocate 912262800 bytes of memory (of type "heap"). Abnormal termination Sending the binary in smaller chunks (4kB) also fails. I get to send about 50 such chunks before I get {error, channel_closed}, but a few moments later the VM freezes with pinned CPU. I am continuing to investigate, but would happily take hints if anyone can provide them. I am running R15B01 on Windows. My use case is to push a firmware image from my Erlang app to a network appliance running OpenSSH. Similar to... cat firmware.bin | ssh someuser@REDACTED 'cat >/temp/firmware.bin' Thanks, Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Mon Aug 27 21:01:47 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Mon, 27 Aug 2012 21:01:47 +0200 Subject: [erlang-bugs] heart prevents beam from creating crash dumps In-Reply-To: <503B31AC.3010800@trifork.com> References: <503B31AC.3010800@trifork.com> Message-ID: <503BC41B.9010202@gmail.com> On 2012-08-27 10:37, Erik S?e S?rensen wrote: > It'd probably make better sense to make the heart FD be the special > case, like stdin/out/err are already. > > Alternatively, could the node communicate to heart that it is dumping, > so that heart can leave it be (at least for a while)? That would of > course also make the FD special, so probably no gain. If the FD for heart is known to the C code, it can simply send the "shutdown" code to heart, just as it is done from the Erlang level when the node shuts down cleanly through init:stop(). (This would also prevent heart from interrupting the crash dump due to ping timeout.) The problem is that at the point in the C code when the file descriptors are being closed, you can no longer do anything from Erlang code. You have to have a way of communicating the port number beforehand down to the C code that will write the crash dump, from the Erlang code that starts heart. Of course, it makes heart the special case rather than EPMD (but I agree that closing all file descriptors is a good idea anyway since there may be other services running, so heart is probably the right choice). It also makes the heart protocol hardcoded into the Beam (right now it's only known to heart.erl and heart.c), but perhaps that should be frozen and officially documented anyway, together with the heart.c command line options so that one can more easily write a custom heart command. Maybe also add an option to specify the name of the command. (Right now, heart.erl does HeartCmd="heart -pid ...", so the executed command depends on your path.) /Richard From daniel.goertzen@REDACTED Mon Aug 27 21:26:46 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 27 Aug 2012 14:26:46 -0500 Subject: [erlang-bugs] crash dump on large ssh:connection_send() In-Reply-To: References: Message-ID: Sigh. Never mind. I was tracing a function that passes the 13 MB binary and attempting to pretty print that made the VM freeze. Sorry for the distraction, Dan. On Mon, Aug 27, 2012 at 1:08 PM, Daniel Goertzen wrote: > When I try to send a large binary (13 MB) through an SSH channel using > "ssh:connection_send()", my VM freezes with a CPU pinned and I am forced to > kill it. One time it managed to get this message out: > > Crash dump was written to: erl_crash.dump > eheap_alloc: Cannot allocate 912262800 bytes of memory (of type "heap"). > > > Abnormal termination > > > > > Sending the binary in smaller chunks (4kB) also fails. I get to send > about 50 such chunks before I get {error, channel_closed}, but a few > moments later the VM freezes with pinned CPU. I am continuing to > investigate, but would happily take hints if anyone can provide them. > > > I am running R15B01 on Windows. > > > My use case is to push a firmware image from my Erlang app to a network > appliance running OpenSSH. Similar to... > > cat firmware.bin | ssh someuser@REDACTED 'cat >/temp/firmware.bin' > > > Thanks, > Dan. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Mon Aug 27 21:43:14 2012 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Mon, 27 Aug 2012 21:43:14 +0200 Subject: [erlang-bugs] heart prevents beam from creating crash dumps In-Reply-To: <503BC41B.9010202@gmail.com> References: <503B31AC.3010800@trifork.com> <503BC41B.9010202@gmail.com> Message-ID: <503BCDD2.60109@wanadoo.fr> Hi, some thoughs : as far 'heart' is child of erl, getppid() is not equal to 1 until the parent process exits. we can imagine that the crashdump is created by 'erl' process as crashdump.{pid} before to be renamed to final name by 'heart' process . 'heart' process is able to see that crashdump.{pid} is increasing in size while its parent is not 1 . if its parent becomes 1 , the 'heart' process renames itself the file to final name before restarting the erl command. If the size does not change for the HEART_BEAT_TIMEOUT timeout while parent is not 1, maybe the parent is a zombi. 'heart' kill SIGKILL its parent and restart the erl process. imply that the delay of restart can be twice the HEART_BEAT_TIMEOUT in case of a zombi parent, or any time otherwise (the time the crashdump is created). this is not maybe what it is expected by lot of people. in such case a -safeheart option could be created for this... I don't know if such behaviour can be done on Windows ? regards From daniel.goertzen@REDACTED Mon Aug 27 23:43:08 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 27 Aug 2012 16:43:08 -0500 Subject: [erlang-bugs] ssh bug: bad window_adjust response Message-ID: Okay, I've found the real bug now. :) When Erlang ssh receives a "ssh_msg_channel_window_adjust" message and there is outstanding data to transmit, the code will generate "ssh_msg_channel_data" messages with the wrong channel number. The remote system observes a protocol error and drops the connection. The problem is in ssh_connection.erl approximately line 450: handle_msg(#ssh_msg_channel_window_adjust{recipient_channel = *ChannelId*, bytes_to_add = Add}, #connection{channel_cache = Cache} = Connection, ConnectionPid, _) -> #channel{send_window_size = Size} = Channel0 = ssh_channel:cache_lookup(Cache, ChannelId), {SendList, Channel} = %% TODO: Datatype 0 ? update_send_window(Channel0#channel{send_window_size = Size + Add}, 0, <<>>, Connection), Replies = lists:map(fun({Type, Data}) -> {connection_reply, ConnectionPid, channel_data_msg(*ChannelId*, Type, Data)} % <-- *bzzt, wrong* end, SendList), FlowCtrlMsgs = flow_control(Channel, Cache), {{replies, Replies ++ FlowCtrlMsgs}, Connection}; Below is a trace of a channel where I did a ssh_connection:send() of a 13MB binary. The first window worth of data is correctly sent to channel 2, but the second window of data is incorrectly sent to channel 7. The remote SSH is OpenSSH. See bolded sections below firmware size 13417472 c{<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ssh_msg_channel_open,"session",7,65536,32768,<<0 bytes>>}}]} al{<0.134.0>,"->",ssh_connection,handle_msg,[{ssh_msg_channel_open_confirmation,7,2,0,32768,<<0 bytes>>},{connection,[{7,{<0.145.0>,#Ref<0.0.0.630>}}],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} ling exec now... opening channel {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_requst_reply,{<0.145.0>,#Ref<0.0.0.630>},{open,7}}]} calling ssh exec {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ssh_msg_channel_request,2,"exec",true,[<<16 bytes>>]}}]} {<0.134.0>,"->",ssh_connection,handle_msg,[{ssh_msg_channel_window_adjust,7,87380},{connection,[{7,{<0.145.0>,#Ref<0.0.0.634>}}],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} {<0.134.0>,"->",ssh_connection,handle_msg,[{ssh_msg_channel_success,7},{connection,[{7,{<0.145.0>,#Ref<0.0.0.634>}}],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} ca{<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_requst_reply,{<0.145.0>,#Ref<0.0.0.634>},success}]} lled send_stdin {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ *ssh_msg_channel_data,2*,<<32768 bytes>>}}]} in{<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ *ssh_msg_channel_data,2*,<<32768 bytes>>}}]} {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ *ssh_msg_channel_data,2*,<<21844 bytes>>}}]} i{<0.134.0>,"->",ssh_connection_manager,send_msg,[{flow_control,65583,{channel,"session","exec",<0.145.0>,{<0.145.0>,#Ref<0.0.0.639>},7,65536,32768,false,2,0,32768,false,[{0,<<13330092 bytes>>}]},{<0.145.0>,#Ref<0.0.0.639>},ok}]} o loop {<0.134.0>,"->",ssh_connection,handle_msg,[{*ssh_msg_channel_window_adjust*, *7* ,124222},{connection,[],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ *ssh_msg_channel_data,7*,<<32768 bytes>>}}]} io{<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ *ssh_msg_channel_data,7*,<<32768 bytes>>}}]} loop got{data,7,1,<<"calling_user 101\nfile_user 0\n">>} {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ *ssh_msg_channel_data,7*,<<32768 bytes>>}}]} {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ *ssh_msg_channel_data,7*,<<25918 bytes>>}}]} i{<0.134.0>,"->",ssh_connection,handle_msg,[{ssh_msg_channel_extended_data,7,1,<<29 bytes>>},{connection,[],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} n {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_data,<0.145.0>,{data,7,1,<<29 bytes>>}}]} io loop {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ssh_msg_channel_window_adjust,2,29}}]} {<0.134.0>,"->",ssh_connection,handle_msg,[{ssh_msg_channel_extended_data,7,1,<<25 bytes>>},{connection,[],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_data,<0.145.0>,{data,7,1,<<25 bytes>>}}]} io loop got{data,7,1,<<"proceeding with transfer\n">>} {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ssh_msg_channel_window_adjust,2,25}}]} in io loop {<0.134.0>,"->",ssh_connection,handle_msg,[*{ssh_msg_disconnect,2,"Received data for nonexistent channel 7* .",[]},{connection,[],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_data,<0.145.0>,{closed,7}}]} {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_data,<0.132.0>,{closed,6}}]} {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_data,<0.132.0>,{closed,5}}]} Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.anderton.andin@REDACTED Tue Aug 28 08:57:23 2012 From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin) Date: Tue, 28 Aug 2012 08:57:23 +0200 Subject: [erlang-bugs] ssh bug: bad window_adjust response In-Reply-To: References: Message-ID: <503C6BD3.8060109@erix.ericsson.se> Hello! Yes that is a bug, thanks for catching it. I will fix it. Regards Ingela Erlang OTP/team - Ericsson AB Daniel Goertzen wrote: > Okay, I've found the real bug now. :) > > When Erlang ssh receives a "ssh_msg_channel_window_adjust" message and > there is outstanding data to transmit, the code will generate > "ssh_msg_channel_data" messages with the wrong channel number. The > remote system observes a protocol error and drops the connection. > > The problem is in ssh_connection.erl approximately line 450: > > handle_msg(#ssh_msg_channel_window_adjust{recipient_channel = *ChannelId*, > bytes_to_add = Add}, > #connection{channel_cache = Cache} = Connection, > ConnectionPid, _) -> > > #channel{send_window_size = Size} = > Channel0 = ssh_channel:cache_lookup(Cache, ChannelId), > > {SendList, Channel} = %% TODO: Datatype 0 ? > update_send_window(Channel0#channel{send_window_size = Size + Add}, > 0, <<>>, Connection), > > Replies = lists:map(fun({Type, Data}) -> > {connection_reply, ConnectionPid, > channel_data_msg(*ChannelId*, Type, Data)} % <-- *bzzt, wrong* > end, SendList), > FlowCtrlMsgs = flow_control(Channel, Cache), > {{replies, Replies ++ FlowCtrlMsgs}, Connection}; > > > Below is a trace of a channel where I did a ssh_connection:send() of a > 13MB binary. The first window worth of data is correctly sent to > channel 2, but the second window of data is incorrectly sent to > channel 7. The remote SSH is OpenSSH. See bolded sections below > > firmware size 13417472 > c{<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ssh_msg_channel_open,"session",7,65536,32768,<<0 > bytes>>}}]} > al{<0.134.0>,"->",ssh_connection,handle_msg,[{ssh_msg_channel_open_confirmation,7,2,0,32768,<<0 > bytes>>},{connection,[{7,{<0.145.0>,#Ref<0.0.0.630>}}],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} > ling exec now... > opening channel > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_requst_reply,{<0.145.0>,#Ref<0.0.0.630>},{open,7}}]} > calling ssh exec > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ssh_msg_channel_request,2,"exec",true,[<<16 > bytes>>]}}]} > {<0.134.0>,"->",ssh_connection,handle_msg,[{ssh_msg_channel_window_adjust,7,87380},{connection,[{7,{<0.145.0>,#Ref<0.0.0.634>}}],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} > {<0.134.0>,"->",ssh_connection,handle_msg,[{ssh_msg_channel_success,7},{connection,[{7,{<0.145.0>,#Ref<0.0.0.634>}}],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} > ca{<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_requst_reply,{<0.145.0>,#Ref<0.0.0.634>},success}]} > lled send_stdin > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{*ssh_msg_channel_data,2*,<<32768 > bytes>>}}]} > in{<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{*ssh_msg_channel_data,2*,<<32768 > bytes>>}}]} > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{*ssh_msg_channel_data,2*,<<21844 > bytes>>}}]} > i{<0.134.0>,"->",ssh_connection_manager,send_msg,[{flow_control,65583,{channel,"session","exec",<0.145.0>,{<0.145.0>,#Ref<0.0.0.639>},7,65536,32768,false,2,0,32768,false,[{0,<<13330092 > bytes>>}]},{<0.145.0>,#Ref<0.0.0.639>},ok}]} > o loop > {<0.134.0>,"->",ssh_connection,handle_msg,[{*ssh_msg_channel_window_adjust*,*7*,124222},{connection,[],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{*ssh_msg_channel_data,7*,<<32768 > bytes>>}}]} > io{<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{*ssh_msg_channel_data,7*,<<32768 > bytes>>}}]} > loop got{data,7,1,<<"calling_user 101\nfile_user 0\n">>} > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{*ssh_msg_channel_data,7*,<<32768 > bytes>>}}]} > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{*ssh_msg_channel_data,7*,<<25918 > bytes>>}}]} > i{<0.134.0>,"->",ssh_connection,handle_msg,[{ssh_msg_channel_extended_data,7,1,<<29 > bytes>>},{connection,[],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} > n > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_data,<0.145.0>,{data,7,1,<<29 > bytes>>}}]} > io loop > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ssh_msg_channel_window_adjust,2,29}}]} > {<0.134.0>,"->",ssh_connection,handle_msg,[{ssh_msg_channel_extended_data,7,1,<<25 > bytes>>},{connection,[],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_data,<0.145.0>,{data,7,1,<<25 > bytes>>}}]} > io loop got{data,7,1,<<"proceeding with transfer\n">>} > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{connection_reply,<0.135.0>,{ssh_msg_channel_window_adjust,2,25}}]} > in io loop > {<0.134.0>,"->",ssh_connection,handle_msg,[*{ssh_msg_disconnect,2,"Received > data for nonexistent channel > 7*.",[]},{connection,[],65583,[],8,undefined,undefined,undefined,undefined,undefined,undefined,<0.133.0>},<0.135.0>,client]} > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_data,<0.145.0>,{closed,7}}]} > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_data,<0.132.0>,{closed,6}}]} > {<0.134.0>,"->",ssh_connection_manager,send_msg,[{channel_data,<0.132.0>,{closed,5}}]} > > > Dan. > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From daniel.goertzen@REDACTED Tue Aug 28 16:08:03 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Tue, 28 Aug 2012 09:08:03 -0500 Subject: [erlang-bugs] ssh bug: bad window_adjust response In-Reply-To: <503C6BD3.8060109@erix.ericsson.se> References: <503C6BD3.8060109@erix.ericsson.se> Message-ID: Thanks. This diff seems to work for me: $ diff -Nbaur ssh_connection.erl.bak ssh_connection.erl --- ssh_connection.erl.bak 2012-08-28 08:20:36.340557700 -0500 +++ ssh_connection.erl 2012-08-28 08:21:50.425465200 -0500 @@ -445,7 +445,7 @@ Replies = lists:map(fun({Type, Data}) -> {connection_reply, ConnectionPid, - channel_data_msg(ChannelId, Type, Data)} + channel_data_msg(Channel#channel.remote_id, Type, Data)} end, SendList), FlowCtrlMsgs = flow_control(Channel, Cache), {{replies, Replies ++ FlowCtrlMsgs}, Connection}; Dan. On Tue, Aug 28, 2012 at 1:57 AM, Ingela Anderton Andin < ingela.anderton.andin@REDACTED> wrote: > Hello! > > Yes that is a bug, thanks for catching it. I will fix it. > > Regards Ingela Erlang OTP/team - Ericsson AB > > Daniel Goertzen wrote: > >> Okay, I've found the real bug now. :) >> >> When Erlang ssh receives a "ssh_msg_channel_window_**adjust" message and >> there is outstanding data to transmit, the code will generate >> "ssh_msg_channel_data" messages with the wrong channel number. The remote >> system observes a protocol error and drops the connection. >> >> The problem is in ssh_connection.erl approximately line 450: >> >> handle_msg(#ssh_msg_channel_**window_adjust{recipient_**channel = >> *ChannelId*, >> >> bytes_to_add = Add}, #connection{channel_cache = Cache} = Connection, >> ConnectionPid, _) -> >> #channel{send_window_size = Size} = Channel0 = >> ssh_channel:cache_lookup(**Cache, ChannelId), >> {SendList, Channel} = %% TODO: Datatype 0 ? >> update_send_window(Channel0#**channel{send_window_size = Size + Add}, >> 0, <<>>, Connection), >> Replies = lists:map(fun({Type, Data}) -> {connection_reply, >> ConnectionPid, >> channel_data_msg(*ChannelId*, Type, Data)} % <-- *bzzt, wrong* >> >> end, SendList), >> FlowCtrlMsgs = flow_control(Channel, Cache), >> {{replies, Replies ++ FlowCtrlMsgs}, Connection}; >> >> >> Below is a trace of a channel where I did a ssh_connection:send() of a >> 13MB binary. The first window worth of data is correctly sent to channel >> 2, but the second window of data is incorrectly sent to channel 7. The >> remote SSH is OpenSSH. See bolded sections below >> >> firmware size 13417472 >> c{<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> connection_reply,<0.135.0>,{**ssh_msg_channel_open,"session"**,7,65536,32768,<<0 >> bytes>>}}]} >> al{<0.134.0>,"->",ssh_**connection,handle_msg,[{ssh_** >> msg_channel_open_confirmation,**7,2,0,32768,<<0 >> bytes>>},{connection,[{7,{<0.**145.0>,#Ref<0.0.0.630>}}],** >> 65583,[],8,undefined,**undefined,undefined,undefined,** >> undefined,undefined,<0.133.0>}**,<0.135.0>,client]} >> ling exec now... >> opening channel >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> channel_requst_reply,{<0.145.**0>,#Ref<0.0.0.630>},{open,7}}]**} >> calling ssh exec >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> connection_reply,<0.135.0>,{**ssh_msg_channel_request,2,"**exec",true,[<<16 >> bytes>>]}}]} >> {<0.134.0>,"->",ssh_**connection,handle_msg,[{ssh_** >> msg_channel_window_adjust,7,**87380},{connection,[{7,{<0.** >> 145.0>,#Ref<0.0.0.634>}}],**65583,[],8,undefined,** >> undefined,undefined,undefined,**undefined,undefined,<0.133.0>}** >> ,<0.135.0>,client]} >> {<0.134.0>,"->",ssh_**connection,handle_msg,[{ssh_** >> msg_channel_success,7},{**connection,[{7,{<0.145.0>,#** >> Ref<0.0.0.634>}}],65583,[],8,**undefined,undefined,undefined,** >> undefined,undefined,undefined,**<0.133.0>},<0.135.0>,client]} >> ca{<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> channel_requst_reply,{<0.145.**0>,#Ref<0.0.0.634>},success}]} >> lled send_stdin >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> connection_reply,<0.135.0>,{***ssh_msg_channel_data,2*,<<**32768 >> bytes>>}}]} >> in{<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> connection_reply,<0.135.0>,{***ssh_msg_channel_data,2*,<<**32768 >> bytes>>}}]} >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> connection_reply,<0.135.0>,{***ssh_msg_channel_data,2*,<<**21844 >> bytes>>}}]} >> >> i{<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> flow_control,65583,{channel,"**session","exec",<0.145.0>,{<0.** >> 145.0>,#Ref<0.0.0.639>},7,**65536,32768,false,2,0,32768,**false,[{0,<<13330092 >> bytes>>}]},{<0.145.0>,#Ref<0.**0.0.639>},ok}]} >> o loop >> {<0.134.0>,"->",ssh_**connection,handle_msg,[{*ssh_** >> msg_channel_window_adjust*,*7***,124222},{connection,[],65583,** >> [],8,undefined,undefined,**undefined,undefined,undefined,** >> undefined,<0.133.0>},<0.135.0>**,client]} >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> connection_reply,<0.135.0>,{***ssh_msg_channel_data,7*,<<**32768 >> bytes>>}}]} >> io{<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> connection_reply,<0.135.0>,{***ssh_msg_channel_data,7*,<<**32768 >> bytes>>}}]} >> >> loop got{data,7,1,<<"calling_user 101\nfile_user 0\n">>} >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> connection_reply,<0.135.0>,{***ssh_msg_channel_data,7*,<<**32768 >> bytes>>}}]} >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> connection_reply,<0.135.0>,{***ssh_msg_channel_data,7*,<<**25918 >> bytes>>}}]} >> >> i{<0.134.0>,"->",ssh_**connection,handle_msg,[{ssh_** >> msg_channel_extended_data,7,1,**<<29 bytes>>},{connection,[],65583,** >> [],8,undefined,undefined,**undefined,undefined,undefined,** >> undefined,<0.133.0>},<0.135.0>**,client]} >> n {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> channel_data,<0.145.0>,{data,**7,1,<<29 bytes>>}}]} >> io loop >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> connection_reply,<0.135.0>,{**ssh_msg_channel_window_adjust,**2,29}}]} >> {<0.134.0>,"->",ssh_**connection,handle_msg,[{ssh_** >> msg_channel_extended_data,7,1,**<<25 bytes>>},{connection,[],65583,** >> [],8,undefined,undefined,**undefined,undefined,undefined,** >> undefined,<0.133.0>},<0.135.0>**,client]} >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> channel_data,<0.145.0>,{data,**7,1,<<25 bytes>>}}]} >> io loop got{data,7,1,<<"proceeding with transfer\n">>} >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> connection_reply,<0.135.0>,{**ssh_msg_channel_window_adjust,**2,25}}]} >> in io loop >> {<0.134.0>,"->",ssh_**connection,handle_msg,[*{ssh_**msg_disconnect,2,"Received >> data for nonexistent channel 7*.",[]},{connection,[],65583,** >> [],8,undefined,undefined,**undefined,undefined,undefined,** >> undefined,<0.133.0>},<0.135.0>**,client]} >> >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> channel_data,<0.145.0>,{**closed,7}}]} >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> channel_data,<0.132.0>,{**closed,6}}]} >> {<0.134.0>,"->",ssh_**connection_manager,send_msg,[{** >> channel_data,<0.132.0>,{**closed,5}}]} >> >> >> Dan. >> >> ------------------------------**------------------------------** >> ------------ >> >> ______________________________**_________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-bugs >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.anderton.andin@REDACTED Wed Aug 29 17:27:27 2012 From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin) Date: Wed, 29 Aug 2012 17:27:27 +0200 Subject: [erlang-bugs] R15B01: PUBLIC_KEY: unable to decode auth_keys/pubkeys with comments In-Reply-To: <1340875528.3506.16.camel@ax-sze> References: <1340875528.3506.16.camel@ax-sze> Message-ID: <503E34DF.3070409@erix.ericsson.se> Hi! We will fix this, but alas we do not have time to fix it for the upcoming release. Thanks for altering us. Regards Ingela Erlang/OTP team - Ericsson AB Stefan Zegenhagen wrote: > Dear all, > > the public_key application fails to decode SSH public keys from *.pub > files or the authorized_keys file when the key has comments with > whitespace in between. > > The key file is split at whitespace boundaries and the function > mend_split() in pubkey_ssh.erl is used to extract the relevant pieces > (KeyType, KeyData, ...). > > When the key comment contains whitespace, the mend_split() function > fails to merge the pieces of the comment into a single string and causes > badmatch exceptions in do_openssh_decode/3. > > Since the format of the "known_hosts" file and the "authorized_keys" or > *.pub files is fundamentally different, it might be necessary to have > different functions to parse them. > > Kind regards, > > From Ingela.Anderton.Andin@REDACTED Wed Aug 29 17:51:46 2012 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Wed, 29 Aug 2012 17:51:46 +0200 Subject: [erlang-bugs] R15B01: PUBLIC_KEY: unable to decode auth_keys/pubkeys with comments In-Reply-To: <503E34DF.3070409@erix.ericsson.se> References: <1340875528.3506.16.camel@ax-sze> <503E34DF.3070409@erix.ericsson.se> Message-ID: <503E3A92.1010306@ericsson.com> Ingela Anderton Andin wrote: > Hi! > > We will fix this, but alas we do not have time to fix it for the > upcoming release. > Thanks for altering us. ^^^^^^ alerting! > > Regards Ingela Erlang/OTP team - Ericsson AB > > Stefan Zegenhagen wrote: >> Dear all, >> >> the public_key application fails to decode SSH public keys from *.pub >> files or the authorized_keys file when the key has comments with >> whitespace in between. >> >> The key file is split at whitespace boundaries and the function >> mend_split() in pubkey_ssh.erl is used to extract the relevant pieces >> (KeyType, KeyData, ...). >> >> When the key comment contains whitespace, the mend_split() function >> fails to merge the pieces of the comment into a single string and causes >> badmatch exceptions in do_openssh_decode/3. >> >> Since the format of the "known_hosts" file and the "authorized_keys" or >> *.pub files is fundamentally different, it might be necessary to have >> different functions to parse them. >> >> Kind regards, >> >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs