I was just in the process of writing David Fernandez Gonzalez an Email about this problem when I came across this ticket.
I can confirm this problem on Ubuntu 18.04.6. My 20.x machines did not get the update, so I cannot verify on other releases:
Unpacking cron (3.0pl1-128.1ubuntu1.1) over (3.0pl1-128.1ubuntu1) ...
Setting up cron (3.0pl1-128.1ubuntu1.1) ...
stat: cannot stat '*': No such file or directory
stat: cannot stat '*': No such file or directory
stat: cannot stat '*': No such file or directory
Warning: * is not a regular file!
Every single sysadmin should be concerned. ANY TIME we see asterisk wildcards being used in this fashion, where [ or test operators are behaving in this manner, we have reason to become concerned. To me, this smells of a shell script trying to parse crontab entries, which is inherently dangerous.
I am now questioning whether or not this postinst script potentially nuked something it shouldn't have.
I was just in the process of writing David Fernandez Gonzalez an Email about this problem when I came across this ticket.
I can confirm this problem on Ubuntu 18.04.6. My 20.x machines did not get the update, so I cannot verify on other releases:
Unpacking cron (3.0pl1- 128.1ubuntu1. 1) over (3.0pl1- 128.1ubuntu1) ... 128.1ubuntu1. 1) ...
Setting up cron (3.0pl1-
stat: cannot stat '*': No such file or directory
stat: cannot stat '*': No such file or directory
stat: cannot stat '*': No such file or directory
Warning: * is not a regular file!
Every single sysadmin should be concerned. ANY TIME we see asterisk wildcards being used in this fashion, where [ or test operators are behaving in this manner, we have reason to become concerned. To me, this smells of a shell script trying to parse crontab entries, which is inherently dangerous.
I am now questioning whether or not this postinst script potentially nuked something it shouldn't have.
How this was missed is beyond me.