Spotted while working on a security bug fix (PiRogueToolSuite/deb-packages#45): the way we generate the dashboard password and the way we inject it into pirogue-admin can lead to a complete failure of the initial pirogue-base installation.
The password is generated with:
# We want an admin password with 64 base64 URL-safe characters and a Wi-Fi
# passphrase that's 16 hexadecimal digits, which means requesting 48 and
# 8 bytes respectively:
generated_secrets = {
'DASHBOARD_PASSWORD': secrets.token_urlsafe(48),
'WIFI_PASSPHRASE': secrets.token_hex(8),
}
(cf. pirogue-admin/pirogue_admin/cmd/cli.py in this repository)
Then the password is injected via:
files:
- src: grafana.ini
dst: /etc/grafana/
# Things we might want to make customizable in there: instance_name
# (PiRogue), http_port (3000), admin_user (admin), admin_password (PiRogue).
variables:
- name: DASHBOARD_PASSWORD
actions:
- /usr/sbin/grafana-cli admin reset-admin-password @DASHBOARD_PASSWORD@
- name: fix-grafana-permissions
- name: restart-grafana
(cf. pirogue-dashboard/admin/index.yaml in the https://github.com/PiRogueToolSuite/deb-packages one.)
Unfortunately, the former can generate passwords that starts with a dash, which means the password turns out to be considered as a very lengthy list of options by grafana-cli, since it's not guarded by an explicit -- that would usually mark the place after which no more options are to be expected.
It might make sense to check whether grafana-cli supports -- (I didn't) and to add it if that's indeed supported; but I think it would make sense to avoid generating/setting such a password in the first place.
A stupid benchmark suggests the frequency is around 1.56%:
import secrets
n=0
N=10000000
for _ in range(N):
if secrets.token_urlsafe(48).startswith('-'):
n += 1
print(f'{n} out of {N}: {100*n/N:.2f}%')
# sample output: 1562623 out of 100000000: 1.56%
And I happen to hit that long before reaching my 10th installation…
Spotted while working on a security bug fix (PiRogueToolSuite/deb-packages#45): the way we generate the dashboard password and the way we inject it into
pirogue-admincan lead to a complete failure of the initialpirogue-baseinstallation.The password is generated with:
(cf.
pirogue-admin/pirogue_admin/cmd/cli.pyin this repository)Then the password is injected via:
(cf.
pirogue-dashboard/admin/index.yamlin the https://github.com/PiRogueToolSuite/deb-packages one.)Unfortunately, the former can generate passwords that starts with a dash, which means the password turns out to be considered as a very lengthy list of options by
grafana-cli, since it's not guarded by an explicit--that would usually mark the place after which no more options are to be expected.It might make sense to check whether
grafana-clisupports--(I didn't) and to add it if that's indeed supported; but I think it would make sense to avoid generating/setting such a password in the first place.A stupid benchmark suggests the frequency is around 1.56%:
And I happen to hit that long before reaching my 10th installation…