From priestjim@REDACTED Sat Aug 1 00:43:19 2015 From: priestjim@REDACTED (Papadomitsos Panagiotis) Date: Fri, 31 Jul 2015 15:43:19 -0700 Subject: [erlang-bugs] Failure to decode EC private key via public_key application Message-ID: <55BBFA07.3030300@gmail.com> Hi all, I've been trying to read an EC password protected private key in pem format into Erlang but I've been getting this error: {ok, M} = file:read_file("m.key"), [Pem] = public_key:pem_decode(M), exception error: no function clause matching pubkey_pbe:cipher({'PBES2-params_encryptionScheme', {2,16,840,1,101,3,4,1,42}, {asn1_OPENTYPE, <<4,16,255,71,145,188,80,110,6,134,174, 100,0,176,46,76,243,205>>}}) (pubkey_pbe.erl, line 271) in function pubkey_pbe:decrypt_parameters/2 (pubkey_pbe.erl, line 185) in call from pubkey_pem:decode_encrypted_private_keyinfo/1 (pubkey_pem.erl, line 146) in call from pubkey_pem:decode_pem_entries/2 (pubkey_pem.erl, line 121) This is in Erlang 18.0.2, both on MacOS 10.10.4 and Ubuntu 14.04. OpenSSL is 1.0.1f. A sample key in the format that causes the issue is: -----BEGIN ENCRYPTED PRIVATE KEY----- MIHeMEkGCSqGSIb3DQEFDTA8MBsGCSqGSIb3DQEFDDAOBAhIMXJLXX+miQICCAAw HQYJYIZIAWUDBAEqBBD/R5G8UG4Ghq5kALAuTPPNBIGQSk3UlBws+Y/BiJg5KIyV IuqsCngm+l10zFNFVrFQNlFQ8+nQHuHYOMXk5UCoqMPkAVD+xSJ1pj00wQiQ85Y5 XS3B9YObYN5iSzFOyTe4S9+qJtW2OI5VQ5gW7xq9LMUKBwJzkpsd9w5lyOgN9/Gt Meq24+3LkqP8DjB7L5fc9U+1F9+BMoUuE+HiLBy6Sww3 -----END ENCRYPTED PRIVATE KEY----- -- Panagiotis Papadomitsos -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.r.nilsson@REDACTED Tue Aug 4 14:33:30 2015 From: hans.r.nilsson@REDACTED (Hans Nilsson R) Date: Tue, 4 Aug 2015 14:33:30 +0200 Subject: [erlang-bugs] SSH library does not conform to the RFC standard In-Reply-To: References: Message-ID: <55C0B11A.3010706@ericsson.com> Hi, you are right in that the group14 is not implemented in ssh-4.0 and so is neither echd. However, all this is in the backlog and diffie-hellman-group14-sha1 as well as diffie-hellman-group-exchange-sha1 and -sha256 is on its way out. Group14 is implemented but has not run the tests yet, but will hopefully pass tonight. Dh-group-exchange is not yet complete - there is no way for a user to add groups yet. It will appear on github soon. It must so far be enabled explicitly by the option prefered_algorithms. A little preview of some days in the future: Eshell V7.0.1 (abort with ^G) 1> Supported = ssh_transport:supported_algorithms(). [{kex,['diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1', 'diffie-hellman-group-exchange-sha256', 'diffie-hellman-group-exchange-sha1']}, {public_key,['ssh-rsa','ssh-dss']}, {cipher,[{client2server,['aes128-ctr','aes128-cbc', '3des-cbc']}, {server2client,['aes128-ctr','aes128-cbc','3des-cbc']}]}, {mac,[{client2server,['hmac-sha2-256','hmac-sha1']}, {server2client,['hmac-sha2-256','hmac-sha1']}]}, {compression,[{client2server,[none,zlib,'zlib@REDACTED']}, {server2client,[none,zlib,'zlib@REDACTED']}]}] 2> ssh:start(). ok 3> ssh:daemon(1234, [{preferred_algorithms,Supported}]). {ok,<0.48.0>} 4> See what we got in our daemon... $ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. SSH-2.0-Erlang/4.0.1 SSH-2.0- d 3??5??(% ??~diffie-hellman-group14-sha1,diffie- hellman-group1-sha1,diffie-hellman-group-exchange- sha256,diffie-hellman-group-exchange-sha1 aes128-ctr,aes128- cbc,3des-cbc aes128-ctr,aes128-cbc,3des-cbchmac-sha2-256,hmac- sha1hmac-sha2-256,hmac-sha1none,zlib,zlib@REDACTED none,zlib,zlib@REDACTED?????^C^CConnection closed by foreign host. $ Ecdh is the next step. /Hans On 07/03/2015 08:07 PM, Adam Krupicka wrote: > Hi, > > I recently tried to play with distributed CT (Common Tests); these > require the ability to open a SSH connection to the target host to start > the remote nodes. It was there that I found that Erlang is unable to > open a SSH connection to an up-to-date, defautly-configured OpenSSH > server. The SSH Erlang library only supports a single Kex (key-exchange > algorithm): diffie-hellman-group1-sha1. The RFC[1], however, > specifically requests that every SSH implementation must also support > the diffie-hellman-group14-sha1 algorithm. The current version of > OpenSSH (OpenSSH_6.8p1, OpenSSL 1.0.2c 12 Jun 2015) in its default > configuration only accepts: > curve25519-sha256@REDACTED , > ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, > diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha1. > I've been told in #erlang on irc.freenode.net > that the SSH library was probably only meant to access Erlang systems > running SSH shells, however, the CT implementation depends on being able > to connect to a real OpenSSH server; that is, on a correct > implementation of the SSH standard. > I thought fixing this would be just a matter of implementing the correct > Kex algorithm, but upon looking at the source I saw that the current > implementation of the Kex algorithms seems to be a bit of a hack[2]. > > Can you please confirm that this is indeed a bug? I did also come across > other people having what I consider to be the same issue[3]. > > > Thanks, > A. K. > > > > [1] https://tools.ietf.org/html/rfc4253#section-8.2 > [2] > https://github.com/erlang/otp/blob/74a95b3d511177a9b35c2b0272b9ca5511b6f750/lib/ssh/src/ssh_transport.erl#L367 > [3] > https://stackoverflow.com/questions/31193906/cannot-connect-to-openssh-using-otp-ssh-module > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From akrupicka@REDACTED Tue Aug 4 17:14:59 2015 From: akrupicka@REDACTED (Adam Krupicka) Date: Tue, 04 Aug 2015 17:14:59 +0200 Subject: [erlang-bugs] SSH library does not conform to the RFC standard In-Reply-To: <55C0B11A.3010706@ericsson.com> References: <55C0B11A.3010706@ericsson.com> Message-ID: <1438700927-sup-7576@arch.local> > However, all this is in the backlog and diffie-hellman-group14-sha1 as > well as diffie-hellman-group-exchange-sha1 and -sha256 is on its way out. Great news :) SSH is a terrific protocol and I'm glad it is going to be properly supported in Erlang. A. K. From sdl.web@REDACTED Thu Aug 6 02:19:02 2015 From: sdl.web@REDACTED (Leo Liu) Date: Thu, 06 Aug 2015 08:19:02 +0800 Subject: [erlang-bugs] eunit:test/2 return value Message-ID: I have noticed the return value may be `error' instead of `{error, Rsn}'. Is it a documentation error? Here is an example: -include_lib("eunit/include/eunit.hrl"). basic_test_() -> [?_assert(1 + 1 =:= 3)]. Leo From tavaresbm@REDACTED Thu Aug 13 13:36:39 2015 From: tavaresbm@REDACTED (Bruno Matos Tavares) Date: Thu, 13 Aug 2015 12:36:39 +0100 Subject: [erlang-bugs] OTP-18.0 --enable-native-libs build failed on Ubuntu Server 14.04 LTS (HVM) and Amazon Linux AMI 2015.03 (HVM) Message-ID: <4AD03703-0875-44E8-AB84-584C96EB13D2@gmail.com> Hi, I?m trying to build Erlang 18.0 from the official tarball with --enable-native-libs and it fails (log at the bottom). After discussing the issue on erlang-questions (https://groups.google.com/forum/#!topic/erlang-programming/OnMkdZpml8E) --enable-native-libs seems not to be working at all on Ubuntu Server 14.04 LTS (HVM) and Amazon Linux AMI 2015.03 (HVM) (the ones I was able to test) but with a workaround only the HiPE applications gets the native libs treatment. * without workaround ./configure --prefix=/usr/local \ --disable-debug \ --enable-silent-rules \ --enable-m64-build \ --enable-threads \ --enable-smp-support \ --enable-kernel-poll \ --enable-hipe \ --enable-native-libs \ --with-ssl=/usr/bin \ --without-docs \ --without-wx \ --without-javac \ ?without-odbc make make[2]: Entering directory `/home/ec2-user/tmp/tmp_1/otp_src_18.0/lib/hipe' Makefile:72: warning: overriding recipe for target `clean' /home/ec2-user/tmp/tmp_1/otp_src_18.0/make/otp_subdir.mk:29: warning: ignoring old recipe for target `clean' === Entering application hipe make[3]: Entering directory `/home/ec2-user/tmp/tmp_1/otp_src_18.0/lib/hipe/rtl' ERLC ../ebin/hipe_rtl.beam hipe_rtl.erl: internal error in native_compile; crash reason: undef in function hipe:compile/4 called as hipe:compile(hipe_rtl,[], <<70,?,0>>, []) in call from compile:native_compile_1/1 (compile.erl, line 1361) in call from compile:'-internal_comp/4-anonymous-1-'/2 (compile.erl, line 295) in call from compile:fold_comp/3 (compile.erl, line 321) in call from compile:internal_comp/4 (compile.erl, line 305) in call from compile:'-do_compile/2-anonymous-0-'/2 (compile.erl, line 155) make[3]: *** [../ebin/hipe_rtl.beam] Error 1 make[3]: Leaving directory `/home/ec2-user/tmp/tmp_1/otp_src_18.0/lib/hipe/rtl' make[2]: *** [opt] Error 2 make[2]: Leaving directory `/home/ec2-user/tmp/tmp_1/otp_src_18.0/lib/hipe' make[1]: *** [opt] Error 2 make[1]: Leaving directory `/home/ec2-user/tmp/tmp_1/otp_src_18.0/lib' make: *** [libs] Error 2 * with the workaround Drop ?enable-m64-build and add CFLAGS=?-O2 -m64' CFLAGS=?-O2 -m64' ./configure --prefix=/usr/local \ --disable-debug \ --enable-silent-rules \ --enable-threads \ --enable-smp-support \ --enable-kernel-poll \ --enable-hipe \ --enable-native-libs \ --with-ssl=/usr/bin \ --without-docs \ --without-wx \ --without-javac \ ?without-odbc 1> code:is_loaded(gen_server). {file,"/opt/erlang//lib/stdlib-2.5/ebin/gen_server.beam"} 2> code:is_loaded(gen_server). {file,?/opt/erlang//lib/stdlib-2.5/ebin/gen_server.beam?} 3> gen_server:module_info(native). false Thank you, Bruno. From kostis@REDACTED Thu Aug 13 15:11:18 2015 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 13 Aug 2015 15:11:18 +0200 Subject: [erlang-bugs] OTP-18.0 --enable-native-libs build failed on Ubuntu Server 14.04 LTS (HVM) and Amazon Linux AMI 2015.03 (HVM) In-Reply-To: <4AD03703-0875-44E8-AB84-584C96EB13D2@gmail.com> References: <4AD03703-0875-44E8-AB84-584C96EB13D2@gmail.com> Message-ID: <55CC9776.8000603@cs.ntua.gr> On 08/13/2015 01:36 PM, Bruno Matos Tavares wrote: > Hi, > > I?m trying to build Erlang 18.0 from the official tarball with --enable-native-libs and it fails (log at the bottom). After discussing the issue on erlang-questions (https://groups.google.com/forum/#!topic/erlang-programming/OnMkdZpml8E) --enable-native-libs seems not to be working at all on Ubuntu Server 14.04 LTS (HVM) and Amazon Linux AMI 2015.03 (HVM) (the ones I was able to test) but with a workaround only the HiPE applications gets the native libs treatment. > > * with the workaround > Drop ?enable-m64-build and add CFLAGS=?-O2 -m64' > > CFLAGS=?-O2 -m64' ./configure --prefix=/usr/local \ > --disable-debug \ > --enable-silent-rules \ > --enable-threads \ > --enable-smp-support \ > --enable-kernel-poll \ > --enable-hipe \ > --enable-native-libs \ > --with-ssl=/usr/bin \ > --without-docs \ > --without-wx \ > --without-javac \ > ?without-odbc > > 1> code:is_loaded(gen_server). > {file,"/opt/erlang//lib/stdlib-2.5/ebin/gen_server.beam"} > 2> code:is_loaded(gen_server). > {file,?/opt/erlang//lib/stdlib-2.5/ebin/gen_server.beam?} > 3> gen_server:module_info(native). > false Be brave and execute the command: make clean before everything else (i.e. when you get the tarball or at the point where you now are). Then issue a ./otp_build autoconf and then the CFLAGS='...' ./configure ... and make commands as you have them above. Kostis From tavaresbm@REDACTED Thu Aug 13 16:23:31 2015 From: tavaresbm@REDACTED (Bruno Matos Tavares) Date: Thu, 13 Aug 2015 15:23:31 +0100 Subject: [erlang-bugs] OTP-18.0 --enable-native-libs build failed on Ubuntu Server 14.04 LTS (HVM) and Amazon Linux AMI 2015.03 (HVM) In-Reply-To: <55CC9776.8000603@cs.ntua.gr> References: <4AD03703-0875-44E8-AB84-584C96EB13D2@gmail.com> <55CC9776.8000603@cs.ntua.gr> Message-ID: Hi Kostis, Sorry, I forgot to mention that I bumped into https://groups.google.com/forum/#!searchin/erlang-programming/enable-native-libs/erlang-programming/qFJmWtUQHuA/EBHC750-4UYJ. So, I did try: CFLAGS=?-O2 -m64' ./configure --prefix=/usr/local \ --disable-debug \ --enable-silent-rules \ --enable-threads \ --enable-smp-support \ --enable-kernel-poll \ --enable-hipe \ --enable-native-libs \ --with-ssl=/usr/bin \ --without-docs \ --without-wx \ --without-javac \ --without-odbc make clean ./otp_build autoconf CFLAGS=?-O2 -m64' ./configure --prefix=/usr/local \ --disable-debug \ --enable-silent-rules \ --enable-threads \ --enable-smp-support \ --enable-kernel-poll \ --enable-hipe \ --enable-native-libs \ --with-ssl=/usr/bin \ --without-docs \ --without-wx \ --without-javac \ --without-odbc make The error is different: === Entering application syntax_tools make[3]: Entering directory `/home/ec2-user/tmp/otp_src_18.0/lib/syntax_tools/src' ERLC ../ebin/erl_syntax.beam ERLC ../ebin/erl_prettypr.beam ERLC ../ebin/erl_syntax_lib.beam ERLC ../ebin/erl_comment_scan.beam erl_comment_scan.erl: internal error in native_compile; crash reason: undef in function hipe:compile/4 called as hipe:compile(erl_comment_scan,[], <<70,79,..,52>>, []) in call from compile:native_compile_1/1 (compile.erl, line 1361) in call from compile:'-internal_comp/4-anonymous-1-'/2 (compile.erl, line 295) in call from compile:fold_comp/3 (compile.erl, line 321) in call from compile:internal_comp/4 (compile.erl, line 305) in call from compile:'-do_compile/2-anonymous-0-'/2 (compile.erl, line 155) make[3]: *** [../ebin/erl_comment_scan.beam] Error 1 make[3]: *** Waiting for unfinished jobs.... erl_prettypr.erl: internal error in native_compile; crash reason: undef in function hipe:compile/4 called as hipe:compile(erl_prettypr,[], <<70, ..>>, []) in call from compile:native_compile_1/1 (compile.erl, line 1361) in call from compile:'-internal_comp/4-anonymous-1-'/2 (compile.erl, line 295) in call from compile:fold_comp/3 (compile.erl, line 321) in call from compile:internal_comp/4 (compile.erl, line 305) in call from compile:'-do_compile/2-anonymous-0-'/2 (compile.erl, line 155) make[3]: *** [../ebin/erl_prettypr.beam] Error 1 erl_syntax_lib.erl: internal error in native_compile; crash reason: undef in function hipe:compile/4 called as hipe:compile(erl_syntax_lib,[], <<70, .., []) in call from compile:native_compile_1/1 (compile.erl, line 1361) in call from compile:'-internal_comp/4-anonymous-1-'/2 (compile.erl, line 295) in call from compile:fold_comp/3 (compile.erl, line 321) in call from compile:internal_comp/4 (compile.erl, line 305) in call from compile:'-do_compile/2-anonymous-0-'/2 (compile.erl, line 155) make[3]: *** [../ebin/erl_syntax_lib.beam] Error 1 erl_syntax.erl: internal error in native_compile; crash reason: undef in function hipe:compile/4 called as hipe:compile(erl_syntax,[], <<70,79,..>>, []) in call from compile:native_compile_1/1 (compile.erl, line 1361) in call from compile:'-internal_comp/4-anonymous-1-'/2 (compile.erl, line 295) in call from compile:fold_comp/3 (compile.erl, line 321) in call from compile:internal_comp/4 (compile.erl, line 305) in call from compile:'-do_compile/2-anonymous-0-'/2 (compile.erl, line 155) make[3]: *** [../ebin/erl_syntax.beam] Error 1 make[3]: Leaving directory `/home/ec2-user/tmp/otp_src_18.0/lib/syntax_tools/src' make[2]: *** [opt] Error 2 make[2]: Leaving directory `/home/ec2-user/tmp/otp_src_18.0/lib/syntax_tools' make[1]: *** [opt] Error 2 make[1]: Leaving directory `/home/ec2-user/tmp/otp_src_18.0/lib' make: *** [tertiary_bootstrap_build] Error 2 Thank you, Bruno. > On 13 Aug 2015, at 14:11, Kostis Sagonas wrote: > > On 08/13/2015 01:36 PM, Bruno Matos Tavares wrote: >> Hi, >> >> I?m trying to build Erlang 18.0 from the official tarball with --enable-native-libs and it fails (log at the bottom). After discussing the issue on erlang-questions (https://groups.google.com/forum/#!topic/erlang-programming/OnMkdZpml8E) --enable-native-libs seems not to be working at all on Ubuntu Server 14.04 LTS (HVM) and Amazon Linux AMI 2015.03 (HVM) (the ones I was able to test) but with a workaround only the HiPE applications gets the native libs treatment. >> >> * with the workaround >> Drop ?enable-m64-build and add CFLAGS=?-O2 -m64' >> >> CFLAGS=?-O2 -m64' ./configure --prefix=/usr/local \ >> --disable-debug \ >> --enable-silent-rules \ >> --enable-threads \ >> --enable-smp-support \ >> --enable-kernel-poll \ >> --enable-hipe \ >> --enable-native-libs \ >> --with-ssl=/usr/bin \ >> --without-docs \ >> --without-wx \ >> --without-javac \ >> ?without-odbc >> >> 1> code:is_loaded(gen_server). >> {file,"/opt/erlang//lib/stdlib-2.5/ebin/gen_server.beam"} >> 2> code:is_loaded(gen_server). >> {file,?/opt/erlang//lib/stdlib-2.5/ebin/gen_server.beam?} >> 3> gen_server:module_info(native). >> false > > Be brave and execute the command: > > make clean > > before everything else (i.e. when you get the tarball or at the point where you now are). Then issue a > > ./otp_build autoconf > > and then the > > CFLAGS='...' ./configure ... > and > make > > commands as you have them above. > > > Kostis From essen@REDACTED Tue Aug 18 00:40:57 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 18 Aug 2015 00:40:57 +0200 Subject: [erlang-bugs] inet:setops manual: {priority, Integer} is documented twice Message-ID: <55D262F9.8060001@ninenines.eu> http://www.erlang.org/doc/man/inet.html#setopts-2 I think it refers to the same option, but as I am not sure what this option does *exactly* I'm reporting a bug rather than fixing it. First time it mentions the option it says: {priority, Priority} Set the protocol-defined priority for all packets to be sent on this socket. Second time: {priority, Integer} Sets the SO_PRIORITY socket level option on platforms where this is implemented. The behaviour and allowed range varies on different systems. The option is ignored on platforms where the option is not implemented. Use with caution. Second one sounds better though it's probably good to add it's for all packets sent on this socket. Cheers, -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From Aleksander.Nycz@REDACTED Tue Aug 18 09:26:31 2015 From: Aleksander.Nycz@REDACTED (Aleksander Nycz) Date: Tue, 18 Aug 2015 09:26:31 +0200 Subject: [erlang-bugs] gen_fsm:reply returns wrong value In-Reply-To: <559FD23E.4080708@comarch.pl> References: <559FD23E.4080708@comarch.pl> Message-ID: <55D2DE27.30308@comarch.pl> Hello, Manual claims that gen_fsm:reply returns value 'true': http://www.erlang.org/doc/man/gen_fsm.html#reply-2 reply(Caller, Reply) -> true but code shows that different value is returned: %% Send a reply to the client. reply({To,Tag},Reply) -> catch To ! {Tag,Reply}. Regards Aleksander Nycz -- Aleksander Nycz Chief Designer Telco_021 BSS R&D Comarch SA Phone: +48 17 785 5909 Mobile: +48 691 464 275 website: www.comarch.pl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4936 bytes Desc: Kryptograficzna sygnatura S/MIME URL: From essen@REDACTED Tue Aug 18 10:17:51 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 18 Aug 2015 10:17:51 +0200 Subject: [erlang-bugs] inet:setops manual: {priority, Integer} is documented twice In-Reply-To: <55D262F9.8060001@ninenines.eu> References: <55D262F9.8060001@ninenines.eu> Message-ID: <55D2EA2F.2010601@ninenines.eu> In that spirit, more options are duplicate in the SSL manual: man ssl Section SSL OPTION DESCRIPTIONS - SERVER SIDE {psk_identity, string()} Specifies the server identity hint the server presents to the client. {log_alert, boolean()} If false, error reports will not be displayed. {honor_cipher_order, boolean()} If true, use the server's preference for cipher selection. If false (the default), use the client's preference. Description differs very little this time though. On 08/18/2015 12:40 AM, Lo?c Hoguin wrote: > http://www.erlang.org/doc/man/inet.html#setopts-2 > > I think it refers to the same option, but as I am not sure what this > option does *exactly* I'm reporting a bug rather than fixing it. > > First time it mentions the option it says: > > {priority, Priority} > Set the protocol-defined priority for all packets to be sent on > this socket. > > Second time: > > {priority, Integer} > Sets the SO_PRIORITY socket level option on platforms where this is > implemented. The behaviour and allowed range varies on different > systems. The option is ignored on platforms where the option is not > implemented. Use with caution. > > Second one sounds better though it's probably good to add it's for all > packets sent on this socket. > > Cheers, > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From essen@REDACTED Tue Aug 18 10:38:41 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 18 Aug 2015 10:38:41 +0200 Subject: [erlang-bugs] SSL key option docs incorrect? Message-ID: <55D2EF11.7090309@ninenines.eu> Reading http://www.erlang.org/doc/man/ssl.html {key, {'RSAPrivateKey'| 'DSAPrivateKey' | 'ECPrivateKey' |'PrivateKeyInfo', public_key:der_encoded()}} The DER-encoded user's private key. If this option is supplied, it overrides option keyfile. However the code says this: https://github.com/erlang/otp/blob/master/lib/ssl/src/ssl.erl#L802 Doesn't look like it allows 'ECPrivateKey' here? -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From Ingela.Anderton.Andin@REDACTED Tue Aug 18 10:44:57 2015 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 18 Aug 2015 10:44:57 +0200 Subject: [erlang-bugs] SSL key option docs incorrect? In-Reply-To: <55D2EF11.7090309@ninenines.eu> References: <55D2EF11.7090309@ninenines.eu> Message-ID: <55D2F089.3010807@ericsson.com> Hi! It is a bug, there is a PR request to solve it, but it is missing a test case. http://www.github.com/erlang/otp/pull/801 Have not had time to make one myself yet. Regards Ingela Erlang OTP/Team - Ericsson AB On 08/18/2015 10:38 AM, Lo?c Hoguin wrote: > Reading http://www.erlang.org/doc/man/ssl.html > > {key, {'RSAPrivateKey'| 'DSAPrivateKey' | 'ECPrivateKey' > |'PrivateKeyInfo', public_key:der_encoded()}} > The DER-encoded user's private key. If this option is supplied, it > overrides option keyfile. > > However the code says this: > > https://github.com/erlang/otp/blob/master/lib/ssl/src/ssl.erl#L802 > > Doesn't look like it allows 'ECPrivateKey' here? > From Ingela.Anderton.Andin@REDACTED Tue Aug 18 10:58:07 2015 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 18 Aug 2015 10:58:07 +0200 Subject: [erlang-bugs] inet:setops manual: {priority, Integer} is documented twice In-Reply-To: <55D2EA2F.2010601@ninenines.eu> References: <55D262F9.8060001@ninenines.eu> <55D2EA2F.2010601@ninenines.eu> Message-ID: <55D2F39F.7000402@ericsson.com> Hi! The ssl docs aim to have a list of common options (when there is no semantical difference, but an option may be "duplicated" if they have different semantical implications on the client and server side. Regards Ingela Erlang/OTP team - Ericsson AB On 08/18/2015 10:17 AM, Lo?c Hoguin wrote: > In that spirit, more options are duplicate in the SSL manual: > > man ssl > > Section SSL OPTION DESCRIPTIONS - SERVER SIDE > > {psk_identity, string()} > Specifies the server identity hint the server presents to the client. > {log_alert, boolean()} > If false, error reports will not be displayed. > {honor_cipher_order, boolean()} > If true, use the server's preference for cipher selection. If false (the > default), use the client's preference. > > Description differs very little this time though. > > On 08/18/2015 12:40 AM, Lo?c Hoguin wrote: >> http://www.erlang.org/doc/man/inet.html#setopts-2 >> >> I think it refers to the same option, but as I am not sure what this >> option does *exactly* I'm reporting a bug rather than fixing it. >> >> First time it mentions the option it says: >> >> {priority, Priority} >> Set the protocol-defined priority for all packets to be sent on >> this socket. >> >> Second time: >> >> {priority, Integer} >> Sets the SO_PRIORITY socket level option on platforms where this is >> implemented. The behaviour and allowed range varies on different >> systems. The option is ignored on platforms where the option is not >> implemented. Use with caution. >> >> Second one sounds better though it's probably good to add it's for all >> packets sent on this socket. >> >> Cheers, >> > From essen@REDACTED Tue Aug 18 10:59:20 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 18 Aug 2015 10:59:20 +0200 Subject: [erlang-bugs] inet:setops manual: {priority, Integer} is documented twice In-Reply-To: <55D2F39F.7000402@ericsson.com> References: <55D262F9.8060001@ninenines.eu> <55D2EA2F.2010601@ninenines.eu> <55D2F39F.7000402@ericsson.com> Message-ID: <55D2F3E8.9050601@ninenines.eu> These are duplicated only in the SERVER SIDE part of the manual. :-) On 08/18/2015 10:58 AM, Ingela Anderton Andin wrote: > Hi! > > The ssl docs aim to have a list of common options (when there is no > semantical difference, but an option may be "duplicated" if they have > different semantical implications on the client and server side. > > Regards Ingela Erlang/OTP team - Ericsson AB > > On 08/18/2015 10:17 AM, Lo?c Hoguin wrote: >> In that spirit, more options are duplicate in the SSL manual: >> >> man ssl >> >> Section SSL OPTION DESCRIPTIONS - SERVER SIDE >> >> {psk_identity, string()} >> Specifies the server identity hint the server presents to the client. >> {log_alert, boolean()} >> If false, error reports will not be displayed. >> {honor_cipher_order, boolean()} >> If true, use the server's preference for cipher selection. If false (the >> default), use the client's preference. >> >> Description differs very little this time though. >> >> On 08/18/2015 12:40 AM, Lo?c Hoguin wrote: >>> http://www.erlang.org/doc/man/inet.html#setopts-2 >>> >>> I think it refers to the same option, but as I am not sure what this >>> option does *exactly* I'm reporting a bug rather than fixing it. >>> >>> First time it mentions the option it says: >>> >>> {priority, Priority} >>> Set the protocol-defined priority for all packets to be sent on >>> this socket. >>> >>> Second time: >>> >>> {priority, Integer} >>> Sets the SO_PRIORITY socket level option on platforms where this is >>> implemented. The behaviour and allowed range varies on different >>> systems. The option is ignored on platforms where the option is not >>> implemented. Use with caution. >>> >>> Second one sounds better though it's probably good to add it's for all >>> packets sent on this socket. >>> >>> Cheers, >>> >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From ondrej.adamovsky@REDACTED Tue Aug 18 14:31:04 2015 From: ondrej.adamovsky@REDACTED (=?utf-8?B?T25kxZllaiBBZGFtb3Zza8O9?=) Date: Tue, 18 Aug 2015 14:31:04 +0200 Subject: [erlang-bugs] httpc relative redirect bug In-Reply-To: References: Message-ID: Hi, I have stumbled upon a bug in inets application. When a HTTP request (tested using httpc:request/4 call with {relaxed,true} HTTP option) returns redirect (e.g. status 302) with relative address in Location header, it is mishandled. The relative address is simply appended to the path of the base request, which is OK only if the base path is empty. The right approach would be: a) if the relative address starts with /, the base path should be replaced by the relative one b) otherwise, the relative path should be appended to base path with the last segment of the base path removed I understand the inets application was written according to RFC 2616, which required the redirect location to be absolute address and the relative redirect was only an optional expansion. Now, the RFC 2616 is obsoleted by RFC 7231, which allows for the relative redirects (https://tools.ietf.org/html/rfc7231#section-7.1.2) and the creation of the resulting address is specified in RFC 3986 (https://tools.ietf.org/html/rfc3986#section-5.2). Regards, Ond?ej Adamovsk? From Ingela.Anderton.Andin@REDACTED Wed Aug 19 12:45:20 2015 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Wed, 19 Aug 2015 12:45:20 +0200 Subject: [erlang-bugs] inet:setops manual: {priority, Integer} is documented twice In-Reply-To: <55D2F3E8.9050601@ninenines.eu> References: <55D262F9.8060001@ninenines.eu> <55D2EA2F.2010601@ninenines.eu> <55D2F39F.7000402@ericsson.com> <55D2F3E8.9050601@ninenines.eu> Message-ID: <55D45E40.20106@ericsson.com> Hi! Well you are correct that was strange! Seems it happened when a user-contribution was merged, it must have been wrongly based or something. We will fix. Regards Ingela Erlang/OTP team - Ericsson AB On 08/18/2015 10:59 AM, Lo?c Hoguin wrote: > These are duplicated only in the SERVER SIDE part of the manual. :-) > > On 08/18/2015 10:58 AM, Ingela Anderton Andin wrote: >> Hi! >> >> The ssl docs aim to have a list of common options (when there is no >> semantical difference, but an option may be "duplicated" if they have >> different semantical implications on the client and server side. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> On 08/18/2015 10:17 AM, Lo?c Hoguin wrote: >>> In that spirit, more options are duplicate in the SSL manual: >>> >>> man ssl >>> >>> Section SSL OPTION DESCRIPTIONS - SERVER SIDE >>> >>> {psk_identity, string()} >>> Specifies the server identity hint the server presents to the client. >>> {log_alert, boolean()} >>> If false, error reports will not be displayed. >>> {honor_cipher_order, boolean()} >>> If true, use the server's preference for cipher selection. If false (the >>> default), use the client's preference. >>> >>> Description differs very little this time though. >>> >>> On 08/18/2015 12:40 AM, Lo?c Hoguin wrote: >>>> http://www.erlang.org/doc/man/inet.html#setopts-2 >>>> >>>> I think it refers to the same option, but as I am not sure what this >>>> option does *exactly* I'm reporting a bug rather than fixing it. >>>> >>>> First time it mentions the option it says: >>>> >>>> {priority, Priority} >>>> Set the protocol-defined priority for all packets to be sent on >>>> this socket. >>>> >>>> Second time: >>>> >>>> {priority, Integer} >>>> Sets the SO_PRIORITY socket level option on platforms where >>>> this is >>>> implemented. The behaviour and allowed range varies on different >>>> systems. The option is ignored on platforms where the option is not >>>> implemented. Use with caution. >>>> >>>> Second one sounds better though it's probably good to add it's for all >>>> packets sent on this socket. >>>> >>>> Cheers, >>>> >>> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From sdl.web@REDACTED Thu Aug 20 12:23:51 2015 From: sdl.web@REDACTED (Leo Liu) Date: Thu, 20 Aug 2015 18:23:51 +0800 Subject: [erlang-bugs] [PATCH] Improve error message for {error, no_src} in int:int_mod/2 Message-ID: The catch all error message doesn't explain {error, no_src} and is confusing. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-error-message-for-error-no_src-in-int-int_mo.patch Type: text/x-patch Size: 838 bytes Desc: 0001-Improve-error-message-for-error-no_src-in-int-int_mo.patch URL: From ilya.khlopotov@REDACTED Fri Aug 21 01:44:35 2015 From: ilya.khlopotov@REDACTED (ILYA Khlopotov) Date: Thu, 20 Aug 2015 16:44:35 -0700 Subject: [erlang-bugs] Dialyzer crashes with Solver v2 failed: error:function_clause Message-ID: Hi, It looks like my previous report (from different email address) didn't go through. Following spec causes dialyzer to crash -opaque att() :: #att{} | attachment(). More info is here https://gist.github.com/iilyak/25a2534b65b6972bf251 Is it a known issue? BR, ILYA -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Fri Aug 21 08:18:27 2015 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 21 Aug 2015 08:18:27 +0200 Subject: [erlang-bugs] Dialyzer crashes with Solver v2 failed: error:function_clause In-Reply-To: References: Message-ID: <55D6C2B3.3040402@cs.ntua.gr> On 08/21/2015 01:44 AM, ILYA Khlopotov wrote: > Hi, > > It looks like my previous report (from different email address) didn't > go through. > > Following spec causes dialyzer to crash > > |-opaque att() :: #att{} | attachment(). > > More info is here > |https://gist.github.com/iilyak/25a2534b65b6972bf251 > > Is it a known issue? No, it's an unknown issue which also appears in the current 'maint'. We'll look into it. Thanks for your report. Kostis From z@REDACTED Mon Aug 31 22:53:01 2015 From: z@REDACTED (Danil Zagoskin) Date: Mon, 31 Aug 2015 23:53:01 +0300 Subject: [erlang-bugs] CT custom framework leads to group mess Message-ID: Hello! Recently I needed a more verbose error reports in common_test log. Reading the code I found an option to specify a TEST_SERVER_FRAMEWORK environment variable (and it's even documented here: http://www1.erlang.org/documentation/doc-5.8/lib/test_server-3.4/doc/html/write_framework_chapter.html ). I implemented a simple proxy module, and my ct_run started to fail in a very strange way ? it looks for a group from one suite with another suite's group/1 function. I created a minimal set of files to reproduce the bug: https://github.com/stolen/ct_custom_fw_bug Am I doing something wrong with this custom framework? -- Danil Zagoskin | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: