action #71740
closed[sle][security][sle15sp3] New Test: ensure password hash is SHA512
Added by dimstar over 3 years ago. Updated over 3 years ago.
100%
Description
After seeing several times that this manages to degrade, we need an urgent test to catch this already in stagings, not only when a product is published.
Triggered by bug https://bugzilla.opensuse.org/show_bug.cgi?id=1176714
I propose two new tests, to be run on the staging workflows and full product test:
- Create a new user using yast2 users (explicitly check the 'encryption' dialog, ensure SHA512 is preselected); ensure the created user has a SHA512 hashed password in /etc/shadow (starts with $6$)
- Create a user on CLI by means of adduser, change the password using passwd, check it is SHA512 hashed (starts with $6$)
Updated by riafarov over 3 years ago
- Due date set to 2020-10-20
- Category set to New test
- Target version set to SLE 15 SP3
Updated by llzhao over 3 years ago
- Subject changed from New Test: ensure password hash is SHA512 to [sle][security][sle15sp3] New Test: ensure password hash is SHA512
- Assignee set to llzhao
Updated by llzhao over 3 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
Updated by llzhao over 3 years ago
Updated by llzhao over 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100
Resolved: the openQA run is good
https://openqa.suse.de/tests/4796542
Updated by dimstar over 3 years ago
- Status changed from Resolved to In Progress
I propose two new tests, to be run on the staging workflows and full product test:
As far as I can see, this test is not enabled on openSUSE Tumbleweed, and definitively not as indicated in comment 0 in staging runs.
Updated by llzhao over 3 years ago
Sure, I will add this test case to TW as needed.
Generally we prefer to open a new poo for TW test case requirements especially graphic related.
Updated by llzhao over 3 years ago
@dimstar We did not add any SLES test cases to TW staging job group before.
Is it "Others -> Staging Projects" ?
Updated by dimstar over 3 years ago
Correct - Other -> STaging projects is the schedule for Staging projects.
Keep in mind that there is ONLY the DVD available, no download repositories
Updated by llzhao over 3 years ago
dimstar wrote:
Correct - Other -> STaging projects is the schedule for Staging projects.
Keep in mind that there is ONLY the DVD available, no download repositories
Thanks, this test case needs to reuse the qcow2 file generated by "gnome" test case for convenience, can I revise the "Settings" of "gnome" (e.g., PUBLISH_HDD_1=...)?
Updated by dimstar over 3 years ago
That should be possible, yes; But maybe we should do such changes on Monday, just in case there are issues, so we don't have a whole weekend without Staging tests.
Updated by okurz over 3 years ago
llzhao wrote:
dimstar wrote:
Correct - Other -> STaging projects is the schedule for Staging projects.
Keep in mind that there is ONLY the DVD available, no download repositories
Thanks, this test case needs to reuse the qcow2 file generated by "gnome" test case for convenience, can I revise the "Settings" of "gnome" (e.g., PUBLISH_HDD_1=...)?
Please avoid setting PUBLISH_HDD_1 on the generic "gnome" test suite. There are dedicated "create_hdd_…" test suites with the purpose to publish the disk image files.
Updated by dimstar over 3 years ago
The new test added on Tumbleweed fails:
Updated by llzhao over 3 years ago
New PR merged: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/11185
openQA run on TW is PASS: https://openqa.opensuse.org/tests/1431502
@dimstar Marked this poo to resolved please reopen it if any issues on TW.
@okurz Got it, thanks :). I did not touch "gnome" test case.
Updated by llzhao over 3 years ago
- Status changed from In Progress to Resolved
- Estimated time changed from 24.00 h to 32.00 h
Updated by dimstar over 3 years ago
- Status changed from Resolved to In Progress
After seeing several times that this manages to degrade, we need an urgent test to catch this already in stagings, not only when a product is published.
I'm still missing (or haven't seen) a test in Staging that will allow us to detect this early
Updated by llzhao over 3 years ago
dimstar wrote:
After seeing several times that this manages to degrade, we need an urgent test to catch this already in stagings, not only when a product is published.
I'm still missing (or haven't seen) a test in Staging that will allow us to detect this early
OK, yes I had hesitated if I should add this case to "Staging" but I was afraid my way may not very match your style so I think you might like to add it.
Added this code to "Job templates for group Staging Projects":
+ - create_hdd_gnome-staging:
+ machine: 64bit
+ priority: 45
+ - yast2_users-staging:
+ machine: 64bit
+ priority: 45
Let's see next openQA run.
Updated by dimstar over 3 years ago
First Staging test run (Staging:B) resulted failure:
https://openqa.opensuse.org/tests/1435332#step/add_users/29
Would be interesting to know what's the difference to the working one in TW (they should be representative/equal)
Updated by llzhao over 3 years ago
- Status changed from In Progress to Resolved
- Estimated time changed from 32.00 h to 40.00 h
Updated by llzhao over 3 years ago
dimstar wrote:
First Staging test run (Staging:B) resulted failure:
https://openqa.opensuse.org/tests/1435332#step/add_users/29
Would be interesting to know what's the difference to the working one in TW (they should be representative/equal)
Yes, it is weird.
Most of the needles are mismatch.
I have revised the needles and the code accordingly:
PR merged: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/11214
And openQA run is good:
Staging group: https://openqa.opensuse.org/tests/1436141
opensuse TW group: https://openqa.opensuse.org/tests/1436140