CFZIP missing attribute(s)


#1

Hi all,

Trying to make use of CFZIP for the first time, but ran into a snag immediately: cfzip in Lucee does not support the password attribute (https://cfdocs.org/cfzip vs https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-u-z/cfzip.html). Hence my venture into CFZIP stopped dead. Any ideas or plans to support this ACF-only (since CF11) attribute?

zip action="unzip" destination="#GetTempDirectory()#" file="#fileName#" password="reallysafepassword" overwrite="true";

Throws the following error:

Details: valid attribute names are [action,charset,destination,entrypath,file,filter,filterdelimiters,name,overwrite,prefix,recurse,showdirectory,source,storepath,variable]
Message: Attribute password is not allowed for statement zip

As a sidenote: anyone have another idea how to download a CSV safely via (S)FTP so I can import it into a MySQL-database? I have the import-part done and working, just need the download-part to be more secure :wink:


#2

can you file a bug with the label acf-compat in jira? ? https://luceeserver.atlassian.net


#3

https://luceeserver.atlassian.net/browse/LDEV-1989


#4

Hi Seb, would you mind editing the title of the bug report to something like “CFZIP: add support for password attribute”? It’s just that these tickets are automatically used to compile changelogs and it’s helpful if they precisely describe the issue.


#5

@Julian_Halliwell Changed it to:
CFZIP: add support for password and encryptionalgorithm attributes


#6

encrypt() or encryptbinary() come to mind, if you’re in control of the CSV file (which it sounds like you are since you’re trying to zip it).

Encrypt the file (encryptbinary()) or the data in the file (encrypt()) and then transfer that via (S)FTP, then decryptbinary() or decrypt() it back to CSV data on the receiving end.

AES/CBC/PKCS5Padding should be used for the algorithm. Encrypt multiple times (with different keys) if you want the extra protection.

HTH

– Denny


#7

Hi @ddspringle, thnx 4 the tip, unfortunately it’s the other way around, I need to download the CSV from somewhere via FTP and I need it to be safely encrypted at their end and then uncrypt it at my end. I guess they’ll have to come up with something and me trying to adapt :wink: Maybe I can get them as far as creating a webservice or something that I can connect to, but it is a Windows system app, so an export is probably the only way to get at the data. Anyways. I see Lucee has proceeded to test and acknowledge the ommission for CFZIP, so hopefully there will be a patched Lucee coming out soon :slight_smile:


#8

Hey @sebgmc Encryption is encryption no matter which operating system or language it is done in, so the workaround still applies. So long as you both use the same secret key, algorithm, encoding and initialization vector then they can encrypt the data on their end and you can decrypt the data on your end seamlessly.

That said, if you’re downloading the CSV over SFTP (and are for sure using SFTP) then that data is SSL/TLS encrypted in transit, just the same as data on an https web page is encrypted in transit, so by itself is a pretty safe option (assuming neither end is using a broken SSL/TLS algorithm, ofc, which by this point neither should be). No reason not to layer additional security measures on top of that, but also no reason you couldn’t rely on the SSL/TLS to keep the data safe in transit, either.

HTH

– Denny