Re: [TCLCORE] Tip 430 First argument handling for Tclsh/Wish (install or detected zip)

[Julian N. <ju...@pr...>]

Perhaps not exactly a mismatch - but I think underexplained in docs...

 From what I can see - zipfs mkzip just encrypts each of the zip file 
content files using the password which is normal - but zipfs mkzip also 
stores it in the archive between the prefix and zip data so the 
automounter can use it.

Someone commented in the tclZipfs.c  "The idea of storing a password 
with the archive seems absurd, encoded or not"

I tend to think it's possibly ok - if it's documented that it's just a 
feature for 'mild obfuscation' - or a mechanism to hinder casual perusal 
of file contents using external zip tools?
By using zipfs mkzip with a password - you're effectively giving the 
password away.
(maybe the same could be said for passwords on a plain zip anyway from a 
cracker perspective - as I assume we're using a pretty basic password 
encryption, but that's not the point I suppose)

I can only imagine the feature of storing the password in the combined 
exe/zip being useful for some sort of 'source available' license where 
they're trying to hint by the mild obfuscation that it's not intended 
for distribution - but perhaps I'm missing other usecases.

My worry is that undocumented - eventually we are just going to get some 
vulnerability report or 'shaming' of Tcl for this - or just someone 
thinking it's magically secure somehow and inadvertently releasing a 
password.
(Possibly the feature should really have been to use some sort of 
indirection so the automounter could look it up from an env var or some 
better password store - but I'm not sure how well that would work with 
initial loading)

Tip 430 only mentions for zip lmkimg that "If password is given , the 
file will be encrypted with that passphrase" - which also doesn't give 
an indication to users that it's actually stored for automounting.
Nor does it make it clear that the encryption doesn't stop you listing 
the contents - as the CDR isn't encrypted - only the file contents 
themselves are unreadable without supplying a password.
That's normal for this sort of basic zip file password - but a common 
surprise - and perhaps not quite what someone may expect from the 
wording 'the file will be encrypted' as in that context it implies the 
outfile.

Cheers,
Julian


On 2024-10-11 6:22 pm, Torsten Berg wrote:
> Hi,
>
> you are right, this feature was never implemented. It should have been 
> added to the "Amendment" section of that TIP but was overlooked. I'll 
> add that right away. There are several mismatches between the TIP and 
> the real implementation. The "Amendment" section is supposed to 
> document these. If you look at the tclsh manual page 
> (https://www.tcl-lang.org/man/tcl9.0/UserCmd/tclsh.html) you will not 
> find that feature documented either. This manual page and the zipfs 
> manual page are the definitive source for reading about the real 
> implementation (unless we have overlooked yet another mismatch ...).
>
> Regards, Torsten
>
>
>> Am 11.10.2024 um 06:06 schrieb Julian Noble via Tcl-Core 
>> <tcl...@li...>:
>>
>> Tip 430 states
>>
>> If the first argument to Tclsh or Wish is detected to be a zipfile, 
>> that file will be mounted as*ZIPFS_ROOT*//app/. 
>> If*ZIPFS_ROOT*//app/main.tcl/exists, that file is marked set the 
>> shell's startup script. If*ZIPFS_ROOT*//app/tcl_library/exists, it 
>> will be searched for/init.tcl/.
>>
>> Is this still meant to be a feature?
>> I've been unable to verify on windows - it just seems to try to run 
>> it as a script, giving the error:
>> couldn't read file "some.zip": invalid or incomplete multibyte or 
>> wide character
>>
>> (same if some.zip replaced with a tclsh that has an attached zip)
>>
>> glancing at the tclZipfs.c code it looks like this feature is 
>> dependent on the SUPPORT_BUILTIN_ZIP_INSTALL flag -  are the 
>> 'install' argument and mounting of first argument if a zip supposed 
>> to be enabled/disabled as a single unit?
>> I couldn't test anyway due to compilation error with that flag 
>> (https://core.tcl-lang.org/tcl/tktview/c5825d3235)
>> As that ticket reports - the 'tclsh install mkimg ..' is suspect anyway
>>
>> Perhaps 'tclsh install/loading first arg if zip' works on other 
>> platforms? Anyone tried it?
>>
>> I feel the mount first argument as a zip is perhaps an unnecessary 
>> feature.
>> Without this magic, it is easy enough anyway to cat a small Tcl 
>> script to the beginning of a zip - along with a ctrl-z character - 
>> and then the script can mount/set auto_paths etc as desired.
>> e.g I have a small file named #z containing the binary <SUB> 
>> character and do:
>> cat kitheader.tcl #z test.zip > kitname.zipkit
>>
>> This works fine.
>>
>> This mount-first-arg-if-zip feature would seem to have potential to 
>> collide with that and I don't currently understand the benefit..
>>  unless it allows dropping into a standard tclsh repl if no main.tcl 
>> is present?
>> That would be nice.
>> (I can do this  if I use a main.tcl-hacked-tclsh with a as per my 
>> earlier message regarding dropping into a standard repl - but 
>> although I've seen the request pop up from users over the years - I 
>> don't see any interest/comments from this list)
>>
>>
>> Cheers,
>> Julian
>>
>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>