Discussion:
Using PerlIO to add an encryption layer
(too old to reply)
Florian Weimer
2006-06-13 09:31:01 UTC
Permalink
I'm trying to implement an encryption layer using PerlIO (in C, not
using PerlIO::via). Is it correct that I shouldn't provide yet another
line discipline like PerlIO::encoding, but a completely new lowest layer (like
the "unix" layer) which happens to use another file handle in its
implementation? After all, the encryption layer is completely opaque as
far as line translation, buffering etc. are concerned, and there doesn't
seem to be a more direct way to encode this in the PerlIO abstraction.
--
Florian Weimer <***@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Durlacher Allee 47 tel: +49-721-96201-1
D-76131 Karlsruhe fax: +49-721-96201-99
Nicholas Clark
2006-06-25 17:05:45 UTC
Permalink
Post by Florian Weimer
I'm trying to implement an encryption layer using PerlIO (in C, not
using PerlIO::via). Is it correct that I shouldn't provide yet another
line discipline like PerlIO::encoding, but a completely new lowest layer (like
the "unix" layer) which happens to use another file handle in its
implementation? After all, the encryption layer is completely opaque as
far as line translation, buffering etc. are concerned, and there doesn't
seem to be a more direct way to encode this in the PerlIO abstraction.
To me it seems more logical to provide a layer that takes data from the
layer below, rather than re-implementing all the logical to open files
close files/maintain file handle state. PerlIO::gzip doesn't worry about
line translation (but because of zlib does need some sort of input buffer)
and it is implemented as a transformation layer akin to PerlIO::encoding,
rather than a lowest layer akin to "unix".

Nicholas Clark
Nick Ing-Simmons
2006-06-26 19:22:16 UTC
Permalink
Post by Florian Weimer
I'm trying to implement an encryption layer using PerlIO (in C, not
using PerlIO::via). Is it correct that I shouldn't provide yet another
line discipline like PerlIO::encoding, but a completely new lowest layer (like
the "unix" layer) which happens to use another file handle in its
implementation? After all, the encryption layer is completely opaque as
far as line translation, buffering etc. are concerned, and there doesn't
seem to be a more direct way to encode this in the PerlIO abstraction.
You could add encryption with an encoding-like layer.
Depending on what you are trying to do and your security concerns
it may make sense to have it as a low level lay (below buffering).

I don't see why it has to replace :unix layer though - it could go just above.
Loading...