Re: Writing libraries for C programs using Guile Scheme

[Mateusz Kowalczyk]

On 08/03/14 16:37, Taylan Ulrich Bayırlı/Kammer wrote:
> Mateusz Kowalczyk <address@hidden> writes:
> 
>> On 08/03/14 00:32, Mark H Weaver wrote:
>>> Mateusz Kowalczyk <address@hidden> writes:
>>>> I doubt that going from a single inherently unsafe but bloody fast
>>>> language to slightly less unsafe but much slower language is an
>>>> advantage here…
>>>
>>> "Slightly less unsafe"?  Seriously?
>>
>> Sure. You get rid of pointer arithmetic which is the beg evil in C but
>> you lose any kind of static typing. It's about as safe as Python, Ruby
>> and whatever new and hip dynamic language is popular today: not a
>> whole lot.
> 
> Your tone makes me unsure whether I should try to argue but, since when
> does "safety" in programming languages have anything to do with static
> as opposed to dynamic type-checking?

There is of course more to safety than that but statically assured
safety is certainly a big deal. I think we could spend a whole lot of
time arguing here about what exactly makes for a safe language but the
thread isn't really about it.

My question is: how will the new libs written in Guile be assured to be
free of security bugs? I only pointed out that Guile itself does not
provide any automatic, static assurances that one could use. It is not
the case against Guile or Scheme or whatever, merely an observation.

> The notion of safety I know prescribes well-defined behavior in error
> situations, and disallowing behavior that doesn't make sense from an
> abstract point of view, which is roughly anything that exposes details
> of the underlying machinery during computation, like the raw
> byte-sequences denoting the abstract entities worked with.  These are
> also, from my knowledge, the main target of security exploits,
> specifically memory unsafety.

This is why I mentioned that there also needs to be assurance that the
generated C parts are immune to such attacks.

> If we treat safety/unsafety as a boolean, then the dynamically typed
> languages you mentioned are safe, whereas C is not; both in terms of
> types and memory, and memory safety is the security-relevant notion of
> safety I know.
> 
> If we were to treat it as a continuum, I would rather call a type-safe,
> memory-safe, dynamically typed language slightly less safe than a
> type-safe, memory-safe, statically typed language, and I'm unsure how
> much this notion of safety is relevant to security exploits.

I find type-safe and dynamically-typed to be a rather weird combination:
dynamic languages tend to pretty much have only a single type, with
many, many instances. Basically all functions take arguments of that
type and if the values don't match up, we get a run-time
error/exception/whatever it is. Comparing ‘types’ in such languages is
no different than comparing two integers. In any case, if you want to
discuss this further I suggest a separate thread or coming on IRC or
whatever. It is not a crucial point of this discussion.

> The mention of speed, by the way, seems very off-the-mark.

It was simply to point out an advantage of using C over using Guile.
Another would be the many eyeballs that looked at the existing library.

> I know nothing about any previous arguments you were in, but from these
> three e-mails alone I'll sadly have to agree that you appear to have a
> bias against so-called "dynamic" languages. :-)

I did not have any previous arguments of such nature on this mailing
list or the #guile IRC channel. I think Mark simply is a bit sour about
some totally unrelated arguments and feels the need to take it out on me.

> Taylan
> 

Again, I'm not saying anything of the sort that Guile is unsuitable to
write a security-critical library in. I'm saying that it is not enough
to simply rewrite library in Guile: extra assurances are needed and I do
not see anywhere in the OP how those will be given. This is not a ‘Guile
vs C/Haskell/Python/anything’ thread, this is not a ‘Guile is unsafe’
thread, this is a ‘where are the assurances of the security of the new
libraries’ thread.

-- 
Mateusz K.