libera/#commonlisp - IRC Chatlog
Search
13:09:10
danisanti
I am thinking about how Common Lisp can improve the security of software and software services. I have been told by a person that most of security attack vectors are a buffer overflow attack. Does Common Lisp suffers from buffer overflow insecurity too (as C does) ?
13:13:14
gilberth
Common Lisp does not suffer from buffer overflows or integer overflows. Why should it?
13:14:11
danisanti
great. Can someone point me to a website that talks about how Common Lisp is more secure than C?
13:30:50
mzan
danisanti: I'm the less knowleadgable here, so maybe they will correct me... CL con compile a package or also only a function with different settings like ``(declaim (optimize (speed 0) (space 0) (debug 3)))``
13:31:33
mzan
If you favour security, CL will check at run-time that the access to arrays is ok, that there is no buffer overflow and so on.
13:32:16
mzan
If you favour speed, the CL compiler can trust the type hints of the programmer, and it can stop to check something at run-time, and you can introduce bugs and security errors.
13:33:19
mzan
BTW, in case of plain CL code, it is more difficult to insert integer overflow, because the default integer type of CL become a bigint in case of overflow.
13:35:11
mzan
danisanti: yes. If for example in C you have int using 64 bits, in CL usually they are 63 bits with the last bit to 0. If the last bit is 1 then the CL runtime check if the "number" is a big-number, or a pointer to an object/struct/etc...
13:36:36
mzan
danisanti: in general CL is more secure/robust of C, because the run-time will check a lot of things at run-time, and it will stop to work if the types are not correct.
13:37:53
mzan
CL is a dynamically typed language, in the sense that every object/reference has a tag at run-time, specifying its type. So they are always checked, but more at run-time than compile-time. So the code is safer, in the sense that in case of errors, instead of doing undefined behaviour, an exception will be signaled.
13:39:19
mzan
The ideal solution is a language that is safe but with types checked at compile-time (statically typed). So you are both sure that there will be no security errors at run-time, but also no exceptions. C is on paper statically typed, but it is too much easy to insert errors at run-time, that are not detected at compile-time. It favours run-time speed, towards security.
13:42:15
gilberth
C is weakly and statically typed, while CL is strongly and dynamically typed. The compiler doesn't help C with the "weak" part.
13:45:55
gilberth
Also having no proper integer data, as C hasn't, is another axis, if you wish to see it that way.
13:47:27
mzan
BTW, CL is multiparadigm language also in these things, because if you add type annotations and change the ``(declaim (optimize (speed 0) (space 0) (debug 3)))`` params, it can bcome in some parts a strongly typed PL at compile time, and weakly typed PL at run-time.
13:48:48
mzan
But the canonical way to use CL is weakly typed at compile-time, and strongly typed at run-time
13:49:20
mzan
yes, I learned here, that it is not good practice setting compilation speed to 3 and debug to 0.
13:49:54
gilberth
That doesn't make sense. No placing a type declaration doesn't make it weakly typed. T is still a type, isn't it?
13:51:15
mzan
I mean that if you put type declaration, and then set speed to 3 and debug to 0, then the compiler is instructed for trusting the type declaration, and maybe it can remove checks at run-time, and it become weakly typed at run-time.
13:57:55
Duuqnd
mzan: Don't you mean safety and not debug? Type checking is still done when using (optimize (debug 0))
14:02:56
danisanti
Ok. I am pretty sure, that as a novice in CL, that I am not gonna change the declaim optimize
14:05:03
danisanti
it should be more talk about, the security aspect of CL when compared to C and compared to Java (and maybe when compared with Rust), so that more people know about this. People that are developing in Rust is most probably because of a security reason, and CL may be able to offer this as well (and more?)
14:06:54
Duuqnd
danisanti: CL can offer a lot, and I guess security is one such thing, mostly because it's a high-level language that's typically implemented well.
14:07:32
danisanti
Rust is a hype and most I believe that people that develop in such a language, don't know about Common Lisp, or else they would develop in Common Lisp
14:08:53
Duuqnd
danisanti: I'm not entirely sure about that. I imagine Rust users have a very different taste in languages than Lispers.
14:09:48
danisanti
ok. I talk from my experience. I never done a poll or a study or something of that matter
14:11:29
nij-
Making a poll wouldn't really work I guess. Those who will be hit by your poll may have a higher chance to know CL.
14:11:50
nij-
What you can do is to go deep into rust, and argue why it doesn't offer much more than CL.
14:12:59
danisanti
Maybe someone that *actually knows* Common Lisp would be a better candidate for that nij-
14:13:59
mfiano
Languages are just tools. Though general purpose, they aren't well-crafted to a particular task, or may not even fit into the tightest of spaces (embedded, etc)
14:15:38
nij-
mfiano But aren't there any language that really has nothing much to offer, besides the fact that they have somehow got populartiy so has a larger community and libraries to use?
14:18:02
mfiano
Of course. Every language your friends or colleagues use are the subject of big corporations backing them. Instead of looking at a language at face value; that is, how popular or the main "gimmick" it tries to hook you with, you should evaluate a language for your task at hand at a deeper level than that.
14:19:11
gilberth
When pondering safety of langanguges, don't forget about integer overflows. Often you don't have an integer data type proper and are stuck with modulo arithmetic.
14:21:35
AadVersteden[m]
I would prefer not to use Common Lisp from o community's perspective. But we still end up using Common Lisp for challenging pieces of software. Part of that is because I somewhat know the language better, but a bigger part is that it's just way more flexible to experiment in.
14:22:21
Josh_2
Macros for reducing the boilerplate when writing an api endpoint and MOP for making endpoints class definitions
14:23:46
nij-
Cool. To me, CLOS is enough.. I can't imagine how MOP is useful. It'd be nice to see some examples.
14:24:31
AadVersteden[m]
The downsides from my perspective are: few people know it, most people can't read it, limited availability of libraries. The upside is that it allows you to express yourself in a very high-level way and you can have both high-level abstractions as well as write performant code, and there are a crazy amount of escape hatches when you learn more about the problem domain.
14:25:47
mfiano
MOP lets you define how CLOS works in any way. You can write your own CLOS using the MOP, as is done in AMOP.
14:26:20
mfiano
and since CLOS is so heavily integrated into the standard, with everything being an object, this becomes pretty flexible.
14:27:10
nij-
"this" in "this becomes pretty flexible" means that you can define how CLOS works in any way?
14:28:37
mfiano
If you need new syntax, macro. if you need new OOP functionality or introspection, MOP.