Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, Therefore I took another route: The existing procedures keep their current defaults, but there is a new set of object constructors that uses only keyword arguments and configures things in a more secure way by default. That seems sensible to me, in particular as making existing APIs behave in backward incompatible ways tends to be ugly. Regarding specific improvements: [procedure] (ssl-make-client-context* #!key ((protocol symbol) 'tls) ((cipher-list string|list) HIGH) ((certificate-authorities string) #f) ((certificate-authority-directory string) #f) ((verify? boolean) #t)) Creates a new client context. Defaults to TLS protocol using only ciphers marked as strong. Loads the certificate authorities from the default directory unless other sources are specified and switches server certificate verification on by default. I'm not convinced HIGH is actually a sensible default selection (it includes ADH cipher suites, for example), or that cipher limitation is even all that important security-wise: If the handshake is not compromised, the parties should not ever select anything braindead unless one side explicitly prefers that and/or doesn't support anything better. Selecting ciphers for specific security properties can be sensible, but it's difficult to find a generally applicable default that's both highly secure and widely compatible. If you control both sides, you might want to use only ciphers with forward secrecy and without MAC-then-encrypt (to avoid padding oracles), for example, but if you make that the default for the egg, you'll find many servers out there that won't know how to talk to you. As for protocol version selection, it would be a good idea to be able to select multiple protocol versions for compatibility with various servers that might not all be able to speak the same version, I guess TLS1.0 and greater is a reasonable default for the time being. Also, I guess it would be good to be able to explicitly select or higher so code specifying that will automatically support newer TLS versions as they become available. As for certificates, it would be totally great if one could also specify the certificate itself directly, without the need to put it into a file, just in case you feel like implementing that ... ;-) Verifying certificates by default is a very good idea indeed. Also, there are a few more things that are advisable to do for secure TLS, some of which (those that apply to the client side) are addressed by the patches that are currently blocked by andyjpb's fix, such as disabling TLS compression and requiring support for secure renegotiation from the server (though the latter may not be supported widely enough yet to make it the default, I'm not sure). On the server side, to make forward secrecy actually work, you have to set up callbacks that supply DH parameters and stuff, it's pretty ugly, but I may be able to supply code snippets if you are interested. Florian ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Interest in SLIME?
Hello Dan, I spent some time today looking into what amount of effort it would take to add swank-trace-dialog support to the existing SLIME egg; it turns out that it's quite doable, but as I have a slew of projects on the go I thought I'd gauge if there's any interest outside of my own inquisitiveness for such an enhancement? I might be interested in this but the times I used slime for chicken it felt a little 'off'. Don't really remember what parts of it though. Maybe they are the parts you've been submitting patches for. I was also looking if I could get some more features into the egg, for example partial completion. Relatedly, I've been submitting patches to fix errors in the SLIME egg that have resulted from code rot; so if you're like me and you use the bleeding edge of Emacs, it should be known that the SLIME egg is sorta usable once again. thanks for that. Does anyone know if eldoc support ever functioned with the SLIME egg? From the wiki: Argument hints start typing an expression (e.g. (call/cc... )) and the argument list will appear in the minibuffer. Note the function must be compiled with debug information. And I can remember it sorta working. But don't take my word for it. cheers, Richard ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Tue, Oct 28, 2014 at 07:35:00AM +0100, Florian Zumbiehl wrote: Hi, Therefore I took another route: The existing procedures keep their current defaults, but there is a new set of object constructors that uses only keyword arguments and configures things in a more secure way by default. That seems sensible to me, in particular as making existing APIs behave in backward incompatible ways tends to be ugly. I agree. It's a bit hairy, but maybe we can get rid of that by changing it for CHICKEN 5 so that ssl-make-client-context is the new one. We're breaking backwards compatibility in core as well, so it makes sense to do the same for mistakes in egg APIs too. Cheers, Peter -- http://www.more-magic.net ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Warning: exit called while processing on-exit tasks
Hello everybody, If I link multiple units into a shared object, load the shared object and call (exit) I get the warning: Warning: exit called while processing on-exit task. If I'm doing this in the interpreter, csi will not exit. Here is a trivial example: $ cat a.scm (declare (unit a)) (define zooi 'a) $ cat b.scm (declare (uses a)) (print zooi) $ csc -c a.scm b.scm ; csc -s a.o b.o -o c.so $ csi #;1 (load c.so) ; loading c.so ... #;2 (print zooi) a #;3 (exit) Warning: exit called while processing on-exit tasks #;4 thanks, Richard ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Warning: exit called while processing on-exit tasks
On Tue, Oct 28, 2014 at 02:13:51PM +, Richard wrote: Hello everybody, If I link multiple units into a shared object, load the shared object and call (exit) I get the warning: Warning: exit called while processing on-exit task. If I'm doing this in the interpreter, csi will not exit. Here is a trivial example: $ cat a.scm (declare (unit a)) (define zooi 'a) $ cat b.scm (declare (uses a)) (print zooi) $ csc -c a.scm b.scm ; csc -s a.o b.o -o c.so I think you need to add -unit to that, otherwise it'll compile adding a main function into those files. Cheers, Peter -- http://www.more-magic.net ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Tue, 28 Oct 2014, Florian Zumbiehl wrote: [...] Regarding specific improvements: [procedure] (ssl-make-client-context* #!key ((protocol symbol) 'tls) ((cipher-list string|list) HIGH) ((certificate-authorities string) #f) ((certificate-authority-directory string) #f) ((verify? boolean) #t)) Creates a new client context. Defaults to TLS protocol using only ciphers marked as strong. Loads the certificate authorities from the default directory unless other sources are specified and switches server certificate verification on by default. I'm not convinced HIGH is actually a sensible default selection (it includes ADH cipher suites, for example), or that cipher limitation is even all that important security-wise: If the handshake is not compromised, the parties should not ever select anything braindead unless one side explicitly prefers that and/or doesn't support anything better. [...] Hello, well, if I understand some of the problems with SSL/TLS in the past years correctly, the fact that a specifically engineered client could force a brain-dead cipher suite selection actually posed a problem several times. But you are certainly right about the non-authenticated schemes, maybe setting the default to HIGH:!aNULL makes more sense? [...] Selecting ciphers for specific security properties can be sensible, but it's difficult to find a generally applicable default that's both highly secure and widely compatible. [...] I think the idea here is to set some defaults that are reasonably secure, even if that means less compatible. If you want to transmit top-secret data you will need something entirely different from SSL/TLS, anyway; and if you don't care about security you can use the old API ;-) [...] As for protocol version selection, it would be a good idea to be able to select multiple protocol versions for compatibility with various servers that might not all be able to speak the same version, I guess TLS1.0 and greater is a reasonable default for the time being. Also, I guess it would be good to be able to explicitly select or higher so code specifying that will automatically support newer TLS versions as they become available. [...] I agree, however the only easy to use presets in the OpenSSL library are SSLv2, SSLv3, TLS or any of them selected automatically. The latter has been the default so far, but that means the vulnerable SSLv3 can be selected, too. Judging by the documentation I'm not even sure whether TLS means TLS 1.0 or TLS in any supported version. It would be great if someone who really groks the OpenSSL API could help out here! [...] As for certificates, it would be totally great if one could also specify the certificate itself directly, without the need to put it into a file, just in case you feel like implementing that ... ;-) [...] Hmm, I remember that was somehow difficult back when I first implemented the old API. I don't recall the reason and I'll just look into it again. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] new egg: arrays
Hi Juergen! Is it possible you've made the same mistake I did with my last egg-announcement, forgetting to provide a URL for us? K. On Oct 28, 2014 5:03 PM, Juergen Lorenz j...@jugilo.de wrote: Hi all, I've just uploaded a new egg, arrays, which contains an implementation of functional arrays, which -- like vectors -- allow fast access to its stored items, but -- unlike vectors -- can shrink and grow as needed. As an application, an implementation of sets is provided. Please give the library a try. Best regards Juergen -- Dr. Juergen Lorenz Flensburger Str. 12 10557 Berlin ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Redefining macros and special forms
Hi, shadowing a macro doesn't seem to work properly in all the cases: (define-syntax my-begin (syntax-rules () ((_ x ...) (begin x ... (let ((my-begin -)) (my-begin 0 1)) ; = -1 (ok) (define my-begin -) (apply my-begin '(0 1)) ; = -1 (ok) (my-begin 0 1) ; = 1 (oops) Thus `my-begin' acts as either a procedure or a macro depending on the context. Redefining `begin' (or even `##core#begin') has the same unsatisfactory behavior: (let ((begin -)) (begin 0 1)) ; = -1 (define begin -) (apply begin '(0 1)) ; = -1 (begin 0 1) ; = 1 Is this the expected behavior? Regards, Michele ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Redefining macros and special forms
On Tue, Oct 28, 2014 at 09:31:44PM +0100, Michele La Monaca wrote: Hi, shadowing a macro doesn't seem to work properly in all the cases: (define-syntax my-begin (syntax-rules () ((_ x ...) (begin x ... (let ((my-begin -)) (my-begin 0 1)) ; = -1 (ok) (define my-begin -) (apply my-begin '(0 1)) ; = -1 (ok) (my-begin 0 1) ; = 1 (oops) Thus `my-begin' acts as either a procedure or a macro depending on the context. Redefining `begin' (or even `##core#begin') has the same unsatisfactory behavior: (let ((begin -)) (begin 0 1)) ; = -1 (define begin -) (apply begin '(0 1)) ; = -1 (begin 0 1) ; = 1 Is this the expected behavior? Yes, this is according to spec. Macros aren't first-class, so whenever you use the same identifier in a non-application context it will look up the identifier in the runtime environment. In application context it will check the syntactic (compile-time) environment first. I agree this is surprising as Scheme is touted to be a Lisp-1, but this is just one of those nasty dark corners of the spec. Cheers, Peter -- http://www.more-magic.net ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Redefining macros and special forms
Hi, shadowing a macro doesn't seem to work properly in all the cases: (define-syntax my-begin (syntax-rules () ((_ x ...) (begin x ... (let ((my-begin -)) (my-begin 0 1)) ; = -1 (ok) (define my-begin -) (apply my-begin '(0 1)) ; = -1 (ok) (my-begin 0 1) ; = 1 (oops) Thus `my-begin' acts as either a procedure or a macro depending on the context. Redefining `begin' (or even `##core#begin') has the same unsatisfactory behavior: (let ((begin -)) (begin 0 1)) ; = -1 (define begin -) (apply begin '(0 1)) ; = -1 (begin 0 1) ; = 1 Is this the expected behavior? Regards, Michele ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Redefining macros and special forms
On Tue, Oct 28, 2014 at 9:35 PM, Peter Bex peter@xs4all.nl wrote: Yes, this is according to spec. Macros aren't first-class, so whenever you use the same identifier in a non-application context it will look up the identifier in the runtime environment. In application context it will check the syntactic (compile-time) environment first. If so, why (let ((begin -)) (begin 0 1)) returns -1? ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Redefining macros and special forms
Michele La Monaca scripsit: Thus `my-begin' acts as either a procedure or a macro depending on the context. Right. Redefining, as opposed to shadowing, a syntax keyword doesn't destroy its definition as a syntax keyword. However, if it's used in a context where it cannot be a syntax keyword, the variable definition is used. That's arguably a bug in Chicken. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory that the mongoose first came to India on a raft from Polynesia. --blurb for Rikki-Kon-Tiki-Tavi ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Florian Zumbiehl scripsit: I am not sure I understand what you mean--you never can protect against a client that doesn't want to protect the session, they always could just publish the session key, or the decrypted data, or whatever. The protection should always focus on third parties that try to undermine the security. There is a difference between a malicious client designed to harm the user, and a merely ignorant client that thinks it's doing the Right Thing but isn't. It's the second kind of client that we need to defend against. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org Today an interactive brochure website, tomorrow a global content management system that leverages collective synergy to drive outside of the box thinking and formulate key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line. --Alex Papadimoulis ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
