1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
Changes in the script api to Trf.
=================================
* KISS (Keep it simple, stupid).
General interface (registry.c)
------------------------------------
Current state
~~~~~~~~~~~~~
a) command ?-option value?... <in_channel> <out_channel>
The so called 'immediate' mode.
b) command ?-option value?... -attach <channel>
'-attach' is an option, and may therefore be put
everywhere. It was placed at the end for emphasis only.
This form actually creates a 'filter' intercepting the
read/writes on the specified <channel>. The filter takes over
the role of the channel it is attached to, allowing to stack
even more filters.
Proposed changes
~~~~~~~~~~~~~~~~
* Use object facilities of 8.0 to allow strings with embedded
'\0's.
* '\0's restrict usage with 7.6, so channel based behaviour must
be retained. This is no issue for 8.1
A) command ?-option value?... <value>
The transformation result is returned as result of the command!
The given value is interpreted as binary data.
B) command ?-option value?... -out <channel> <value>
The transformation result is written into the specified channel.
C) command ?-option value?... -in <channel>
The value is read from the specified channel, the result is
returned.
D) command ?-option value?... -in <in_channel> -out <out_channel>
The value is read from the input channel, the result written to
the output channel. This implements (a).
In words:
* Either use '-in <channel>' or specify the value directly.
* Either use '-out channel' or expect the transformed information
as result of the command.
(b) remains unchanged.
Additional rule
* Usage of '-attach' disallows '-in', '-out', no result will
given, no value expected (#args %2 == 0).
Interface to conversions, and similar transformations
-----------------------------------------------------
Unchanged.
Remark:
Similar transformations are 'rs_ecc' and 'zip'. They can be
seen as conversions too, only with a special set of options.
Interface to ciphers (cipher.c, c_opt.c)
-------------------------------------------
Current state
~~~~~~~~~~~~~
* Ciphers get key information via '-key channel'.
Proposed changes
~~~~~~~~~~~~~~~~
* Interpret the value of '-key' in depencendance of the value of
'-key-type'. This is either 'data' or 'channel', with 'data' as
default.
-key-type data -key <value>: Interpret <value> as binary data.
-key-type channel -key <value>: Interpret <value> as channel handle.
If the key is given as hexstring, or dual, octal, etc, the
following lines will do the trick:
8.0:
cipher -key [hex -mode decode <hexstring>] ...
(case A, see above)
7.6:
create <channel>. | write the hexstring
hex -attach <channel> -mode decode | into a channel,
puts <channel> <hexstring> | decode to binary
unstack <channel> | data too.
seek <channel> 0 |
cipher -key <channel> ...
(This is the current way with 8.x too)
Interface to blockciphers (blockcipher.c, bc_opt.c)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The relevant options are
-key (key information)
-iv (initialization vector for stream modes)
I propose the same changes as with ciphers:
-key, -key-type
-iv, -iv-type
Interface to message digests
----------------------------
Current state
~~~~~~~~~~~~~
* 2 submodes for a filter.
absorb:
identity with respect to user data.
calculates a digest during write, attaches it after the
last character written by the user.
calculates a digest during read, compares it to the
digest after the user data. result goes into an
associated variable.
write:
/dev/null with respect to user data.
calculates digests for read/write, writes them to
destination channels after the primary channel is/was
closed.
Proposed changes
~~~~~~~~~~~~~~~~
* No changes to the immediate mode.
* No changes of filter submode 'absorbtion'.
* Change submode 'write' to allow writing into variables. Use
..-type options to determine the type of destination.
Unsure: Continuously update variables, or write only after
the primary channel was closed, as with channels ?
KISS: Same as with channels.
* Another submode: 'transparent'.
Like 'write' with respect to digest calculation, but identity
for user information, as in 'absorb'.
* rename options
-write-dest, -read-dest
to
-write-destination, -read-destination
Compatible to existing scripts, and names are more clear.
|
