libera/#commonlisp - IRC Chatlog
Search
22:52:33
jcowan
etimmons: It is certainly possible to do crypto or TCP/IP in Lisp (indeed, Interlisp does), but doesn't strike me as a good idea in either case.
22:53:59
hayley
Crypto in C is only marginally easier - I read the OpenSSL developers read the assembler output for what C code they have to make sure it's still constant time.
23:41:59
jcowan
hayley: My point is that you shouldn't write your own crypto code in any language: you should use a widely deployed library.
23:44:07
jcowan
as the saying is, "unless you trust nobody and your crypto skills are second to none"
23:44:21
ulfvonbelow
I always thought "don't roll your own crypto" generally referred to devising cryptographic algorithms, not necessarily writing or porting an implementation
23:46:16
jcowan
That is certainly even worse. But if you are concerned with covert timing channels, porting is also a Bad Thing.
23:50:23
mzan
Is there someone using CL, coming from Scheme? I'm using Racket in some semi-production utility, but I want to test CL.
23:51:17
ulfvonbelow
For sufficiently large probabilistic sets, existential and universal qualifiers become trivially true and false, respectively
0:02:15
ulfvonbelow
heh, I'd say they both have their charm, but I do like the lack of opinion of CL, the gradual typing system, the simplicity of writing macros, and the fact that the standard designers thought of just about everything possible (want to specialize your data structure that requires an integer serialization to hold characters, but don't know how high a char-code can go? CHAR-CODE-LIMIT, built right into the standard!)
0:04:53
mzan
I tried Typed Racket, and it seems very good in this regard. My first impression with CL and SBCL it is that it is all more professional and industrial grade.
1:22:58
hayley
Does anyone know where the Intel intrinsic guide was moved to? It's not at <https://software.intel.com/sites/landingpage/IntrinsicsGuide/> and the search tool isn't really helping.
1:23:39
hayley
(It is for Lisp code, not that anyone cares, but I need to check how the instructions work. And I don't know where else you ask a question like that.)
2:50:13
White_Flame
copec: files could be brought together arbitrarily, you could have your own potentially overlapping groupings of views of related toplevel forms, you could have some things (or just their docstrings) always in view for reference, etc
2:50:49
White_Flame
the model of each having a fixed place in a linear file and only a file-based view is limiting and fundamentally disorganized
2:51:27
White_Flame
and yes, the actual storage doesn't have to match what's onscreen at all in terms of how it composes into a saved artifact
2:51:56
White_Flame
it's similar to not having to manually deal with the b-tree structures in your database when you're just grabbing rows or browsing tables
2:52:21
White_Flame
the file's specific format & on-disk layout should just be a hidden implementation detail
2:52:57
White_Flame
however, CL would have to change, as its toplevel forms are not necessarily unordered declarations, but ordered mutations to an image or compilation unit state
6:50:20
pjb
About cryptography, C compilers can also perform optimizations that could be counter-productive to the security of the cryptographic system. Even writing it in assembler is not a guarantee, since the processor itself may have optimization features or other. It may be difficult to find in a processor, instructions that wouldn't leak some RF or some power usage depending on the data being processed.
6:50:58
pjb
That said, those cryptographic system requirements are not something that can be dealt with at the language level, but at the implementation level.
6:51:37
pjb
It is therefore quite possible to design an implementation with an option to generate code that would be adequate to implement cryptgraphic systems.
6:52:42
pjb
(declaim (declaration tempest-protection)) (defun encrypt (message key) (declare tempest-protection) …)
7:06:00
madnificent
pjb: with infinite research budget, introducing unexpected changes into the layers of abstraction sounds like a great way to create issues which are nearly impossible to catch during a code review. one could even introduce them on another layer after the code has been reviewed.
7:07:02
madnificent
I strongly suspect our reality is much simpler and that many issues found in systems are far simpler than incompatibilities between the layers of abstraction but it would be a cool thing to pursue.
7:17:43
jackdaniel
madnificent: but this comes even without such unobvious things like encryption. you assume that when you write a conforming program you are safe, but implementations have bugs and even interpret differently some parts; there may be changes inside the compiler you did not anticipate
7:18:16
pjb
madnificent: well, implementing an algorithm can be validated. In cryptography, the problem is that it's not sufficient to have a correct algorithm. The code must be written so as to minimize physical and logical side effects induced by the execution of the correct code, that could lead to leaking information about the keys or other cryptographic elements.
7:19:09
pjb
Already, running on a VM is bad, since the VM can see what's occuring. But there are solutions: white-box cryptography, where the key are encrypted, and kept encrypted when used.
7:19:53
pjb
But other statistical properties about the keys could be detected from temperature, power, speed variations (physical phenomenon outside of the direct influence of the algorithm and code).
7:20:47
pjb
Perhaps (setf x (* 2 x)) produces more heat when x is full of 1s instead of full of 0s? Perhaps (setf x (ash x 1)) produces the same heat in both cases?
7:21:11
pjb
Depends on the compiler and hardware. Algorithmically, it's the same. Both codes are correct.
7:21:56
pjb
What I'm saying is that it's better to have a compiler option to let it ensure that the code generated from both forms minimize the heat produced and execution speed variation.
7:22:12
pjb
Actually, that it's the only way to ensure that the cryptographic system requirements are met.
7:22:35
pjb
You must include in the requirement fulfillment the specific compiler and hardware, to validate the cryptographic system.
7:23:19
pjb
So, write all the cryptographic code you want, it's not up to the programmer to ensure validity of the final cryptographic system, but up to the integrator who will select the compiler and compiler options, and the hardware.
7:24:40
pjb
Of course, the designers of cryptographic algorithms can help by avoiding things like "if bit 0 of x is 1 then do-something-taking-little-time-and-energy else do-somethign-taking-a-lot-of-time-and-energy".
8:37:21
JeromeLon
Are there any active projects to make a new lisp IDE or to make alternative/radical improvements to emacs/slime? Code or variable extraction, inlining, renaming, real-time warnings, smarter completion, are all taken for granted nowadays, but are not available when using emacs. Presumable these all require the editor to have a deeper understanding of what each character means, which in turns
8:40:50
beach
This paper http://metamodular.com/incremental-parsing.pdf shows how we use READ (the Eclector version of it) to incrementally parse the buffer contents.
8:41:35
beach
Then the plan is to run the code through the first phase(s) of a compiler-like think to determine determine the role of each expression.
8:42:17
beach
From that result, we compute indentation (which I kind of know how to do, but that I haven't worked out the mechanics of yet) and highlighting information.
8:43:13
beach
Then there is the debugger part. This is what I think we should do: http://metamodular.com/SICL/sicl-debugging.pdf
9:26:48
beach
pjb: Wow, MIT LOOP is worse than what you pointed out. This is SBCL: (loop for x in '(a b c) append (cons x 'foo)) => (a b c . foo)
9:40:24
beach
pjb: (defparameter *l* '(c d)) (tailp *l* (sicl-loop:loop for l in (list '(a b) *l*) append l)) => T
9:40:34
beach
pjb: (defparameter *l* '(c d)) (tailp *l* (cl:loop for l in (list '(a b) *l*) append l)) => NIL
9:49:27
beach
In https://github.com/robert-strandh/SICL/tree/master/Code/Loop there are three files collect-clause.lisp, append-clause.lisp, and nconc-clause.lisp where I changed the methods on BODY-FORM specalized to COLLECT-FORM-CLAUSE, APPEND-FORM-CLAUSE, and NCONC-FORM-CLAUSE respectively. But there is significant duplication, and I did not change the methods specialized to the -IT- or -INTO- clauses. If someone feels like fixing the existin
9:52:10
beach
That someone could also extract the entire LOOP code to a separate repository. Then we would have a LOOP library that is much more conforming that what most implementations currently have.
10:00:40
jackdaniel
doesn't part about append fall into "undefined behavior"? the loop append is specified to exact as the function append and the latter says that arguments (except for the last one) must be proper lists, but doesn't mention what happens when they are not
10:05:55
beach
On the other hand, SBCL APPEND signals an error, and LOOP is supposed to behave as if APPEND were used.
10:07:46
jackdaniel
I'd interpret that: so if they are not proper lists, then undefined consequences follow - expecting uniform undefined consequences would be quite a requirement ;)
10:08:29
beach
It is not terribly important. What is important is that it is better to have a stricter LOOP version than a sloppier one.
10:10:09
beach
Also, I encourage people to replace the native version of LOOP by the SICL one, because it is more strict. Xach has been known to do this to check whether systems in Quicklisp are conforming.
10:10:53
beach
And I encourage maintainers of Common Lisp systems to load SICL LOOP as a replacement for the native one, unless the native one is as conforming of course.
10:17:58
beach
Anyway, time for a lunch break. I'll screen all the candidates when I get back, and make a long list sorted by experience, availability, and attitude.
10:21:39
jackdaniel
people who will replace loop of the implementation of their choosing and maintainers who will replace loop in the implementation