Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backslash as path separator should not be allowed in FMUs #547

Open
t-sommer opened this Issue Mar 8, 2019 · 6 comments

Comments

Projects
None yet
4 participants
@t-sommer
Copy link
Collaborator

t-sommer commented Mar 8, 2019

Using backslashes (\) in the paths of the contained files causes problems on Linux and macOS and should not be allowed. See also fmi-cross-check #43.

@pmai

This comment has been minimized.

Copy link
Collaborator

pmai commented Mar 8, 2019

It already is prohibited by the ZIP Specification, which is referenced by the standard. However given the frequency this crops up, I think an additional sentence reiterating this (as well as the common ./ prefix, which is also not sanctioned by the ZIP Specification) would be a good idea (this was one of many common issues in the FMI Implementers Best Practice Guide by ProStep which are still relevant).

One might also want to add a reference to the zip slip vulnerability https://snyk.io/research/zip-slip-vulnerability, since it is fairly easy to fall into that trap with naive use of zip libs/external programs.

@chrbertsch chrbertsch added this to the FMI2.0.1 milestone Mar 8, 2019

@chrbertsch

This comment has been minimized.

Copy link
Collaborator

chrbertsch commented Mar 8, 2019

This is a 2.0.1 clarfication that should be merged in to 3.0 also, right?

@t-sommer

This comment has been minimized.

Copy link
Collaborator Author

t-sommer commented Mar 9, 2019

The .ZIP File Format Specification is actually quite clear about this (thanks for the hint @pmai):

4.4.17 file name: (Variable)

       4.4.17.1 The name of the file, with optional relative path.
       The path stored MUST NOT contain a drive or
       device letter, or a leading slash.  All slashes
       MUST be forward slashes '/' as opposed to
       backwards slashes '\' for compatibility with Amiga
       and UNIX file systems etc.  If input came from standard
       input, there is no file name field. 

Should we close this?

@chrbertsch

This comment has been minimized.

Copy link
Collaborator

chrbertsch commented Mar 10, 2019

As several implementers have made this mistake, I suggest to either include a hint as non-normative text, or start an "implementers guide" or "technical faq" on the fmi website including this issue.

@andreas-junghanns

This comment has been minimized.

Copy link
Contributor

andreas-junghanns commented Mar 10, 2019

Let's not do that, please: one document is hard enough to keep consistent; two is impossible. We have seen this with cross-check notes, notes for the standard etc. We have a good mechanism: Non-normative text. If what we have there is not perfect, let's fix this, but in the document. If we tag it well in AsciiDoc, the we can possibly turn it on/off for certain exports, but we should keep it one source with all reasonably close together. And for the specific case here, this won't be difficult.

Note: This is why I was opposed to having ProStep publish the otherwise valuable implementers guide: The place for this kind of information is inside the document and if we missed some of these additions, then we can always release a X.Y.1 to add things in.

@chrbertsch

This comment has been minimized.

Copy link
Collaborator

chrbertsch commented Mar 11, 2019

OK. Let's include a reference to the "ZIP File Format Specification" https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT and a hint in non-normative text to use forward slashes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.