7zip inside past sell-by date says Secunia

Apparently the older 9.x line of the 7-zip code has reached an end, though I still see it on the website. Secunia also finds moderate un-safety in it, which may tint their judgement, but argue with them as I have in the early days, I think they are pretty correct about things.

What I tried, not for the faint of heart on this one, is hiving the original dll and exe off in a safely placed zip file, then putting in the same parts from a 16.x line installer. I used 32 bit parts since I’m sure you do for compatibility.

Scrivener 1.9.5.0 seems to zip backups just fine with this, though a much more thorough testing on more complex projects is certainly in order.

Thus I don’t know when you want to introduce this upgrade, if it’s always comforting to see 100% clean from Secunia (I use the old better version as it still works fine, not dumbed down – and never would let it install anything, though I understand their thinking on that).

Best to the team, Antipodean are you all???
Clive
Lee never answers me since I missed him on a Christmas trip, but I did have a reason…

Thanks for the report! We’re aware that this has caused a few security programs to flag the 7-zip component as a potential vulnerability and are looking into the best way to deal with it. The 7-zip component is part of the Doc2Any tools Scrivener uses for creating and importing DOC and DOCX files, and they’re using the 9.x line rather than the 16.x line. We may be able to manually switch these on our end, but since it is part of a third-party tool, there’s a risk that our switching it will cause the DOCX extraction tools to break, which naturally we don’t want. I’d be interested to know how DOCX handling works for you (with the “Microsoft Office” importer and exporter converter options enabled from Tools > Options > Import/Export) since you’ve taken the step of adjusting these for your own system.

Hi MM -

It’s very late (and was off internet for two days prior) so could only give a brief try, but may not be working as expected.

  • what comes out looks good - docx of original, not-challenging Scriv binder item
  • but if I select more than one binder item, wierd results, not entirely consistent. Basically, I get one out of two selected files, or two out of three, in a folder.
  • this could though have to do with the fact that Scriv docs are titled by Dr. Name etc…

I’ll try to give a more informative workout, but not until tomorrow evening - out on appts. the day…

Best,
Clive

I will get to this, I promise.

Interrupted by a very iintense week; wanting to make a really decent stab at a test for it; Scrivener total rewrite due to elsewhere discussed permissions difficulties, etc…

:wink:

p.s. especially since docx seemed to work fine on undemanding doc at first…

Ok, you can see the hour, as the weekend went to finish the project of the week. Do not ask :wink:

I redid the swap of 16-version for 9-version 7zip.exe and .dll, in the expected place. I used the 32-bit versions for your reasons, while all work done on a 64-bit Win10 fatally up-to-date system. Actually, that last Win update seems very good, and I have excellent stability.

Then, I’ve imported several different kinds of exports from a pretty complicated InDesign paper. Especially docx, doc, and rtf. I’m aware I think that you’re interested in output from Scrivener, rather than import, but seemed a decent way also to get complex text. I couldn’t do it straightforwardly without buying plugins, so I exported to HTML, then had Word 2013 read that and export to a handful of formats, which it seemed to do reasonably well.

  • the imports to Scrivener pretty much lost embedded pictures. This probably is not at all Scrivener’s fault, rather Word’s importing a particular flavor of html. There were warnings about it, and I didn’t have time to look into those or make better. So, I embedded a fresh pic or two straight into Scrivener, in appropriate positions, and resized in Scrivener so as tofit the margins.

  • then, I exported to docx, doc, and rtf.

  • The basic thing to say is that it seems everything came through that’s expected. See what you think from these items.

  • all text looks all there and correct over a 20-page-plus formal paper. That includes Chinese, Korean, and Japanese characters, in addition to standard and fairly English English.

  • fonts in the text are correct, both Roman and Asian, for example proper Myriad and Minion on titles and body text.

  • there’s no connection to Word Styles, but from Windows Scrivener at this point I don’t think we expect any, unless I remember vaguely a pretty manual procedure, or redoing them with reasonable efficiency after the fact. In short, I think no problems here.

  • the images I put in came out well. Some different sizing between doc, docx, and rtf, but iwithin any margins, and I don’t think that’s what you’re interested in.

  • Rulers and their margins came through on both doc and docx, when there were any on the original, so again I think you’re ok there also.

Jennifer, I hope for usefulness here to the point that it sounds like doing your own tests.

I hadn’t time to look into why zip is involved, but I guess it may be a basis for keeping down the size of the MS protocols, binary/html or xml for docx. If that’s it, a general compression, I think results look confidence-inspiring.

Trying some other documents to beat it up should give some closure. Very easy to get the zip parts using 7zip on its own installer; I zipped up the old ones in a separate folder to hide them but keep around.

Hope this helps, and apologies time’s so limited…

Clive

p.s. and Scrivener’s backups seem to reopen fine; not sue if this 7zip is what’s used for those, and from what you asked, think not.

Thanks for the thorough testing, Clive, I appreciate it! That sounds quite promising. The 7zip tool here is just used for the conversion to DOCX as part of the “Microsoft Office” converter, not for zipping Scrivener’s backups, which uses the Windows zip utility, but it’s good to know that swapping the tool didn’t break any of that. We’ll run a few tests also and see what we can do about updating the .exe.

Most welcome, MM. I suspect it is promising, and nice if seeing so can help the effort.

Take care,
Clive

Just to say that a Kaspersky vulnerability scan also flags this as a ‘High’ threat:
https://threats.kaspersky.com/en/vulnerability/KLA10823