This was raised by email by @KaraZajac. Right now if 'garbage at end of line' is detected, the previous bits have been succesfully parser and accepted. This is e.g. to make sure incorrect line-endings don't cause full lock-outs.
In the case of other parse-errors (or bugs in the parser), it is conceivable that this causes incomplete config lines to be accepted (albeit with a warning). We could also add code that ensures that, in the case of a "garbage at end of line" error, the part before it is rejected also. This would in effect add some extra defense in depth.
We could also do this in an intelligent manner rather than all-or-nothing; in a similar vein, we ignore NOINTERCEPT as a keyword (sudo-rs emits a warning for it, but the rest of the configuration rule will continue to be understood), but if we encounter INTERCEPT that means we reject the whole rule since we don't implement subcommand interception.
This was raised by email by @KaraZajac. Right now if 'garbage at end of line' is detected, the previous bits have been succesfully parser and accepted. This is e.g. to make sure incorrect line-endings don't cause full lock-outs.
In the case of other parse-errors (or bugs in the parser), it is conceivable that this causes incomplete config lines to be accepted (albeit with a warning). We could also add code that ensures that, in the case of a "garbage at end of line" error, the part before it is rejected also. This would in effect add some extra defense in depth.
We could also do this in an intelligent manner rather than all-or-nothing; in a similar vein, we ignore
NOINTERCEPTas a keyword (sudo-rs emits a warning for it, but the rest of the configuration rule will continue to be understood), but if we encounterINTERCEPTthat means we reject the whole rule since we don't implement subcommand interception.