World: r3wp

and it will load them dynamically later?

ah, that is exactly what I wanted to ask - rebin ...

R3 does not have encryption modules yet, they will probably come 
later. but notice that nobody stops people from linking to OpenSSL 
and provide a complete SSL solution.

not sure if correct, but I can see rebin as kind of "packager" for 
rebol? Will it allow us to pack various things - e.g. libraries, 
scripts, images, or other resources, and add it to the rebol.exe?

(maybe RT will do that, or maybe we'll use the SSL module in R2...)

rebin is a binary format for rebol values. like now we have a text 
format (produced by mold), then we'll also have a binary format useful 
both for storing (when user-readable is not needed) and for internal 
communication with plugins

but... Carl hasn't said much more about rebin...

nobody stops = it is not available yet. With R3 spreading like fire, 
we might need it sooner than later, or we will not be able to provide 
lowered security apps, letting users feel safe, because they will 
know, it comes from some trusted party ....

Services requires encryption so you can bet release version of R3 
will have it.

but, SSL is more than that.

and, R3 might just use the same module found in R2 for SSL

if you need more, you just make your own SSL device.

SSL is specific protocol. I am not speaking about encryption here, 
but about the trust, that is what certificates are for. IIRC the 
api for them is inside, it was not just exposed. And IIRC2, Ladislav 
once mentioned he will do it? But I could misunderstood him ...

certificates are just signed files with public keys.

so... there's nothing really special.

ie you can do that in R2 with mezz code.

what you can't do with mezz code is cert handling for ssl://

so that what i was talking about :)

Gab, you want to tell me, that I can check for certificate validity 
or actually sign something using my certificate, in let's say, PKCS#12 
format?

why not?

R2 has RSA, DES, etc.

Thanks !

We did signing for SurfNet's Stunnel-in-a-box project.

It does not help anyone, if not in rebol directly, that is the point 
...

if that was the case, then we'd need to have everything built in. 
do we want ajax js libraries built in because it does not help anyone 
if cgi authors have to pick them themselves?

then you misunderstand, what is important, and what is not.

today's sw world, distributed, without signatures? The thing is, 
someone from RT confirmed that the stuff is inside, just not exposed. 
And that is waste of resources. So - expose them.

signatures - rebol has that built in. is called rsa encryption

parsing of some file format - that you can do yoursef.

it's not like jpeg decoding that has to be done in c for speed.

how do I choose windows installed certificate? :-)

then you misunderstand, what is important, and what is not.

 -- I think Gabriele misunderstands very little. :-) The thing is, 
 it's all about compromises. What is important to you might not be 
 important to me at all, and vice versa. So how do you choose what 
 to include, and how big is too big for REBOL to be? 


If something is wanted and needed by 80% of the community, or 0.1% 
that's doing something really important, those are easier calls to 
make. Many features have doubtful value to at least some people, 
but we can't use those as justification for adding other things of 
doubtful value. So, I want a good voting system, and tracking for 
new community mezz funcs, to see what gets used the most; what people 
want and need.


That said, I think security is so important now that anything we 
can do to make REBOL a better tool for writing secure systems is 
a good thing.

But I am not talking about new features at all. Someone said, that 
Core contains certificates handling already, which means, even parsing? 
It is the same situation, how Rebol contained internally convolve 
function, which was just not exposed. So, we are talking nearly zero 
addition to Rebol. And not having certificates handling in rebol 
directly is what actually stopped rebol plug-in. If I'll see some 
reblet signed from Gregg, I will not think any second to just press 
"Run". 


I am not now opting for the particular functionality - my question 
was more general. Plug-in development stopped, because Josh stated, 
that he is working on soon-to-be-released new schema for Rebol security. 
We all knew how it would end, and we were not wrong. That is exactly 
the reason, why I ask - there is no plug-in, without the security. 
And plug-in is imo very crucial product now.

Forget certificates right now, before we enter another pointless 
discussion. The thing is, that I believe RT regards reblet signing 
important thing, and that it will come. If it is not part of the 
system, noone will do it, period. The same reason, why RT pushes 
for rebservices - it will be standard without any need for further 
discussion, if we do it this way, or that way ...

you're still confusing signing with certificates. the ssl module 
certainly has to parse certs in the ssl handshake. but that does 
not mean that it will parse any cert file format. and, there are 
many. but... even if it was exposed, what would it save you? three 
lines of parse?

I am not sure I am confusing anything. If it is not there, then it 
is not there. I can give an example - Bobik - he left rebol, because 
of our often claims, that we can do anything. But he is looking for 
the end user tool. He does not want to code mySQL driver himself, 
he wants to use one. So, if you will have website with rebol features, 
what will be your answer to following bullet:

certificates support: 


Yes, or no? Am I able to easily send rebol email, signed, which displays 
in Thunderbird or Outlook, as signed? Am I able to choose from centrally 
installed certificates in Windows certificate container? That is 
my point. So - if it is only 3 lines of code, just take a note, and 
when RT will be thinking of security/privacy issues, please count 
such things in?

send signed email - yes you can do that. does it need to be in send? 
should send also handle return receipts? should it handle gmail apis? 
should it handle exchange servers? where do we stop?

windows cert container - why should rebol even bother about that? 
that's something that 1% of rebolers would maybe need once in their 
life

Do you actually follow corporate environment?

petr, corporate environment means that we should provide 6 dvds of 
rebol ide

we don't want to go there. we want to provide specific solutions, 
not buzzwords

Because last year, I was asking about certificates. There was a possibility 
for me, to have small rebol app, which securely sends and checks 
documents. It could be used for invoices exchange. I stopped because 
noone was able to point me out, how should I check for signatures.

that does not stop you from providing the buzzwords

the detective only executes signed code. the code for that is available.

now is it cert parsing that you want or signing? signing is explained 
on rebol.com

Whereas guys from Delphi crowd were able to do that. Now you can 
blame me, that I was not able to make it. REBOL nor its community 
did not work as enabler for me here. And I can see only one sensible 
way to avoid that in the future - projects domain, bounty system 
...

and worst case - why not use CALL to call openssl??

cert parsing

stopping a project because of that does not seem rebol fault to me.

cert parsing - how much time would have that been? one day? two days? 
if you save a month by using rebol, then what's the problem with 
two days?