the simplest thing to do would be to set "is_email_confirmed=false" for all users - this would have the effect requiring each user to verify their email address in order to log in to pagure for the first time - and yes it would need to be the same email address that they signed up with originally - i have already seen some object to this on the grounds that some folks wish to be so anonymous as not to even keep a valid email address but one could easily argue that a site admin is under no obligation to cater to users who can not be contacted
this should be reasonable for the majority of users - anyone who has been using notabug without a valid email address would simply lose their nickname and would need to create a fresh one - remember that all data such as issues are publicly accessible git repos so it may even be feasible for one user to recreate another user's repo entirely in including PRs, issues, and so on
one idea may be to add a general notice to the top of every page of the current running notabug site starting now - something like:
"notabug will be transitioning to a new system sometime within the next 60 days - ensure that you are able to receive email at your "Primary Email Address" in "Your Settings" or else you will lose your nick name
the simplest thing to do would be to set "is_email_confirmed=false" for all users - this would have the effect requiring each user to verify their email address in order to log in to pagure for the first time - and yes it would need to be the same email address that they signed up with originally - i have already seen some object to this on the grounds that some folks wish to be so anonymous as not to even keep a valid email address but one could easily argue that a site admin is under no obligation to cater to users who can not be contacted
this should be reasonable for the majority of users - anyone who has been using notabug without a valid email address would simply lose their nickname and would need to create a fresh one - remember that all data such as issues are publicly accessible git repos so it may even be feasible for one user to recreate another user's repo entirely in including PRs, issues, and so on
one idea may be to add a general notice to the top of every page of the current running notabug site starting now - something like:
> "notabug will be transitioning to a new system sometime within the next 60 days - ensure that you are able to receive email at your "Primary Email Address" in "Your Settings" or else you will lose your nick name
One of the selling points of using notabug.org for those people is that it works like this. I'm really very much against this solution. We should find a way to support the old password hashes.
One of the selling points of using notabug.org for those people *is* that it works like this. I'm really very much against this solution. We should find a way to support the old password hashes.
the next simplest idea that comes to mind is like this:
create all pagure users with a cleartext password equal to their current gogs password hash
keep the existing gogs site running for a few months alongside the pagure instance but have all functionality of the gogs site removed except for login
upon login to gogs show the user "your pagure password is <the-gogs-pass-hash>"
user can then log into pagure and change their password
note that the disabled gogs site would need to be kept running indefinitely if using this approach alone or else many users are guaranteed to be lost with all of their data orphaned - once the disabled gogs site is finally shut down completely it would then be wise to delete all of this orphaned data and repos as those accounts will be impossible to log into
the next simplest idea that comes to mind is like this:
* create all pagure users with a cleartext password equal to their current gogs password hash
* keep the existing gogs site running for a few months alongside the pagure instance but have all functionality of the gogs site removed except for login
* upon login to gogs show the user "your pagure password is <the-gogs-pass-hash>"
* user can then log into pagure and change their password
note that the disabled gogs site would need to be kept running indefinitely if using this approach alone or else many users are guaranteed to be lost with all of their data orphaned - once the disabled gogs site is finally shut down completely it would then be wise to delete all of this orphaned data and repos as those accounts will be impossible to log into
This I think is how Gogs salts the users' password, and this I think is the implementation of that PBKDF2 function
This instead is how Pagure salts the users' password
[This](https://github.com/gogits/gogs/blob/master/models/user.go#L317) I think is how Gogs salts the users' password, and [this](https://github.com/gogits/gogs/blob/master/modules/base/tool.go#L101) I think is the implementation of that PBKDF2 function
[This](https://pagure.io/pagure/blob/master/f/pagure/lib/login.py#_72) instead is how Pagure salts the users' password
This seems significantly more complicated than just using the python implementation for the same hashing implementation. I don't really like the idea of shelling out to a go binary for a feature that is simply available.
This seems significantly more complicated than just using the python implementation for the same hashing implementation. I don't really like the idea of shelling out to a go binary for a feature that is simply available.
i really did think the python-only implementation was going to be much more complex and error-prone if i had to translate that go function to python - but i poked at it some more today and it turns out that python has a standard library function that implements that same hashing algorithm (its actually in the same library package that pagure already includes) - so today i have a working python-only solution that is even simpler than the previous one - and because it uses a standard library function to do the math i trust that it is as reliable as the original go function
i really did think the python-only implementation was going to be much more complex and error-prone if i had to translate that go function to python - but i poked at it some more today and it turns out that python has a standard library function that implements that same hashing algorithm (its actually in the same library package that pagure already includes) - so today i have a working python-only solution that is even simpler than the previous one - and because it uses a standard library function to do the math i trust that it is as reliable as the original go function
this is on the 'pass-hash' branch of [my pagre fork](https://notabug.org/bill-auger/pagure/src/pass-hash)
this will undoubtedly be the most complex task of migrating to pagure
a part of this will also have to be figuring out what to do with the existing password hashes.
the simplest thing to do would be to set "is_email_confirmed=false" for all users - this would have the effect requiring each user to verify their email address in order to log in to pagure for the first time - and yes it would need to be the same email address that they signed up with originally - i have already seen some object to this on the grounds that some folks wish to be so anonymous as not to even keep a valid email address but one could easily argue that a site admin is under no obligation to cater to users who can not be contacted
this should be reasonable for the majority of users - anyone who has been using notabug without a valid email address would simply lose their nickname and would need to create a fresh one - remember that all data such as issues are publicly accessible git repos so it may even be feasible for one user to recreate another user's repo entirely in including PRs, issues, and so on
one idea may be to add a general notice to the top of every page of the current running notabug site starting now - something like:
One of the selling points of using notabug.org for those people is that it works like this. I'm really very much against this solution. We should find a way to support the old password hashes.
the next simplest idea that comes to mind is like this:
note that the disabled gogs site would need to be kept running indefinitely if using this approach alone or else many users are guaranteed to be lost with all of their data orphaned - once the disabled gogs site is finally shut down completely it would then be wise to delete all of this orphaned data and repos as those accounts will be impossible to log into
This I think is how Gogs salts the users' password, and this I think is the implementation of that PBKDF2 function
This instead is how Pagure salts the users' password
This seems significantly more complicated than just using the python implementation for the same hashing implementation. I don't really like the idea of shelling out to a go binary for a feature that is simply available.
i really did think the python-only implementation was going to be much more complex and error-prone if i had to translate that go function to python - but i poked at it some more today and it turns out that python has a standard library function that implements that same hashing algorithm (its actually in the same library package that pagure already includes) - so today i have a working python-only solution that is even simpler than the previous one - and because it uses a standard library function to do the math i trust that it is as reliable as the original go function
this is on the 'pass-hash' branch of my pagre fork
nice!