Inconsistent flag dashes

[rew1nter]

I noticed this on axiom-scan help. The flag dash patterns do not follow any pattern. This can be confusing to remember the dashes

You could instead do:

1. Single dash for all
2. Double dash for all
3. Single dash for short, Double dash for long (if you're having a short and long form of the same flag)

[0xtavian]

@rew1nter so, the "idea" is that shorthand arguments only get a single dash. We tried to model after nmap's help menu. -anew is an outlier since its not shorthand, but it is an output type. So to keep consistent with all output types we used -anew.

Also for whatever its worth, axiom needs to be very careful with how it determines if a user provided argument is intended for axiom itself, or is it intended to be passed to the instances/module. So we have to keep unique argument names and is one reason why we dont have both a short and long form for every flag.

For example if a tool/module you are distributing has a native -F argument, and you run axiom-scan and add -F to the command line, axiom will consider that argument to be for axiom and never pass it to the tool/module.
The workaround is just hardcoding any potentially troublesome (duplicated) extra args directly to the modules .json file i.e. not adding them to the command-line and expecting axiom to pass the argument to the module.

[rew1nter]

So we have to keep unique argument names

Theoretically, you couldn't keep all argument names unique for axiom since users can add their custom modules with flags you aren't aware of

The workaround is just hardcoding any potentially troublesome (duplicated) extra args directly to the modules

I think it's better for this to be made the only possible way of specifying native arguments. This will reduce complexity and allow axiom to have better flags.

Or you could consider this input system for native flags instead of EXTRA ARGS:

axiom-scan --cache --native "--cache -verbose -t 10 -other-native-flag" --axiom-flag 

Here all the native flags/args will be passed on to one axiom flag called --native and then the axiom can just pass it to the underlying module without having to worry about duplicates.

[0xtavian]

@rew1nter

I think it's better for this to be made the only possible way of specifying native arguments. This will reduce complexity and allow axiom to have better flags.

imo one of the cooler parts of axiom is how we interpolate user provided command line args (extra args) directly to the module. But it comes with the downside you describe.

Or you could consider this input system for native flags instead of EXTRA ARGS:
axiom-scan --cache --native "--cache -verbose -t 10 -other-native-flag" --axiom-flag

this is an option. I would really prefer to also keep the automatic EXTRA ARGS interpolation. At the very least for backwards compatibility, so everyone doesnt have to rewrite their automation if they are currently providing EXTRA ARGS.

I think what I can do is, if an option like --native (will likely call it --extra-args) is used, axiom wont try to determine which args are intended for axiom and which are intended for the module. and instead rely on the user provided args specified after the --extra-args flags, like how you suggest.

I'll continue to thing about this. Thanks.

[0xtavian]

@rew1nter something like this? https://github.com/pry0cc/axiom/blob/explicit-extra-args/interact/axiom-scan

explicitly define extra args to be passed

axiom-scan input -m nmapx --extra-args '-sV --open'

Automatically pass extra args

axiom-scan input -m nmapx -sV --open

Something like this will pass -sV --open but wont pass -T4 -p- (at least for now, but I could change that easily enough)

axiom-scan input -m nmapx --extra-args '-sV --open' -T4 -p-

[rew1nter]

Something like this will pass -sV --open but wont pass -T4 -p-

yes exactly that

At the very least for backwards compatibility, so everyone doesnt have to rewrite their automation

I agree. But you can't keep this feature around forever since this is the root cause of this flag issue.

If you'll be implementing this, what I would suggest is putting the deprecation message of this feature up on the repo, along with the new alternative, for 6 - 10 months and also printing a log message from axiom script about this. So users can take their sweet time updating the automation before this feature gets deprecated.