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.
14:29:20
nij-
I see. So the thing that confuses me is what sort of new OOP functionality would possibly make life easier.
14:29:46
Josh_2
nij-: take a look at https://github.com/K1D77A/lisp-pay/tree/main/src in protocol.lisp and mop.lisp that might help
14:31:03
mfiano
Perhaps being able to change the parents of an instance at runtime, by inserting mixins into the superclasses of the class of the instance, giving your instance new behavior (applicable methods) and data (parent slots)
14:32:47
Josh_2
I am pretty sure I am only really playing with a small subset of it, I didn't find much of AMOP very helpful either.
14:33:55
mzan
Duuqnd: ah ok, sorry. I confused debug with safety. You are right. In this example I used debug for the right reason BTW. There were code I want to study, and so I want to trace it without the danger of advanced compile-time optimizations.
14:34:17
AadVersteden[m]
I used the MOP to write an object layer on top of Postgres at some point. You build a meta-class and that can alter behavior. It's cool that you can write such a thing in a very natural way in the object system.
14:34:36
mfiano
With the MOP, you could define a new subtype of a generic function that is able to dispatch using an arbitrary function (like Clojure), rather than by class-name or EQL.
14:35:39
mfiano
and this has been done in a few different libraries available in Quicklisp, if you wanted to play around with that.
14:36:05
AadVersteden[m]
None of these features are things that would be a total blocker if you wouldn't have it. It would still be possible to write something that works. It's just that it becomes harder to write such things and at some point it's not worth the investment anymore.
14:36:46
Josh_2
In my experience playing with the MOP is often quite a time consuming task but it yields highly flexible results.
14:37:10
Josh_2
So often I would mess with MOP as a refactor where I am trying to increase the flexibility of my code
14:37:26
mfiano
I have heard. I have not played with it, probably because it slipped out of my mind with the years it has been inactive :)
14:39:30
mfiano
I am not sure, but phoe might still be writing CLR2 in his free time, and he requested to use one of my uses of the MOP for one of the new recipes. When that gets released, I think we'll have some actual concrete MOP examples all in one place.
14:40:43
mzan
nij-: I will do an unjustified claim, but maybe it is true. I studied also a little of Smalltalk. Advanced frameworks in Smalltalk uses a lot the meta object protocol. Every class has a metaclass, so you can customize every detail of class and instances behaviour. In practice it is a sort of MOP. Smalltalk can do a lot of complex things at run-time, that in CL you do at compile-time, using macro. So MOP can be used like meta class are used in
14:42:15
Josh_2
Everything you said about Smalltalk is applicable to CL, except that it is normally performed at compile time, although you can define classes at runtime if you wish
14:43:29
mzan
Powerfull OOP intrespection, reflection and metaclass tecniques are used in Smalltalk a lot, and they can be used in CLOS and MOP too.
14:52:12
nij-
"""mfiano > With the MOP, you could define a new subtype of a generic [..] dispatch using an arbitrary function (like Clojure), rather than by class-name or EQL.""""
14:52:32
nij-
Wow this is cool. Does it also allow defining generic functions that take arbitrary many parameters?
14:53:43
mfiano
Check out Pascal Constanza's paper on filtered-functions (easily google-able), and the associated repository for one implementation.
14:55:26
nij-
This sounds very nice. Now I did remember playing with a pet project, and wished that I could extend CLOS.
14:56:05
nij-
Is it fair to say that MOP is 'just' a framework that allows you to treat any class as an object, and therefore you can hack every detail of that class?
14:57:10
Bike
i think that would be pretty reductive. for one thing it's not just classes that are objects
14:59:21
nij-
How would you describe what MOP is then? I find it interesting, and think it is something that one should be comfortable with first in order to summon its full power.
15:00:41
Bike
it's probably put more artfully in the book, but something like: a protocol that makes the parts of the object system itself implemented as extensible objects
15:00:46
mfiano
It's a protocol that specifies how objects are to be defined, constructed, and otherwise manipulated.
15:02:30
mfiano
Therefor, since generic functions, part of CLOS are available in CL, you can extend the MOP's protocol by intercepting with different hooks into the various object data flow pipelines