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

Issues with files containing wildcards #2

Closed
jgoerzen opened this issue Mar 1, 2022 · 1 comment
Closed

Issues with files containing wildcards #2

jgoerzen opened this issue Mar 1, 2022 · 1 comment

Comments

@jgoerzen
Copy link

jgoerzen commented Mar 1, 2022

Hello!

Thank you for maintaining this fork of NetBSD mtree. I maintain mtree-netbsd for Debian and will likely switch to this fork.

I submitted a report here NetBSD/pkgsrc#101 about incorrect processing during verification of filenames that contain asterisks. The fix appears to be this:

--- verify.c.orig       2018-08-22 15:48:38.000000000 -0500
+++ verify.c    2022-03-01 09:45:04.854574448 -0600
@@ -142,9 +142,7 @@
                if (specdepth != p->fts_level)
                        goto extra;
                for (ep = level; ep; ep = ep->next)
-                       if ((ep->flags & F_MAGIC &&
-                           !fnmatch(ep->name, p->fts_name, FNM_PATHNAME)) ||
-                           !strcmp(ep->name, p->fts_name)) {
+                       if (!strcmp(ep->name, p->fts_name)) {
                                ep->flags |= F_VISIT;
                                if (compare(ep, p))
                                        rval = MISMATCHEXIT;

It is a little unclear to me if anybody is actually trying to use the undocumented feature of expanding globs in the spec file; AFAICT, no tool ever generates that and it seems highly unlikely that it was ever used anywhere.

Also in that discussion it looks like NetBSD may deprecate the pkgsrc tree, and this would probably be a logical "upstream" for Debian, Arch, and so forth.

@archiecobbs
Copy link
Owner

I agree that's pretty bogus and possibly dangerous. Should be fixed in 3b4dd49.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants