In my humble opinion it is a design flaw, because the user is not told to not insert "too" long SSH keys
When do you need this? (YYYY/MM/DD) Well I would have needed it now.
When is this no longer needed or useful? (YYYY/MM/DD) I don't know
If we cannot complete your request, what is the impact? I cannot use all my SSH keys
Metadata Update from @pingou: - Issue tagged with: src.fp.o
Metadata Update from @bowlofeggs: - Issue priority set to: Waiting on Assignee (was: Needs Review)
@germano ,
Not to discount your concern, but 8196 bit rsa keys are not 'typical' in this day and age, mostly it's 4096 or some variant of the ed25519/ecdsa/{insert ecc curve here}. You indicate having 3 keys, these are all for Fedora ??? Arguably the quickest and easiest fix to this would be to make some rsa4096 key(s) or ecc keys for Fedora uses, and return to https://admin.fedoraproject.org/accounts and browse to these new key(s) and upload and within ~ 30 or the next timed sync whichever comes first you should be able to login as desired.
Note: If you need to access any host that is still running on RHEL/CentOS 6 it will NOT work with a ecc key ( presently and likely not thru the lifecycle of those hosts from my understanding) so I'd advise rsa4096. While 8196 is nice to have most services don't natively support it, or have cookie space for them.
Hope this helps at least in expanding on puiterwijk's (Patrick) comments last week.
@pingou so we could go to OIDC on the web interface of pagure anytime? Or are we waiting for the api to be done first?
Alternately, we could try a small fas patch to reject too long ssh keys, but not sure how hard that would be or if we want to update fas.
Metadata Update from @cverna: - Issue tagged with: high-trouble, low-gain
Metadata Update from @smooge: - Issue tagged with: dev
@pingou so we could go to OIDC on the web interface of pagure anytime?
Technically yes
Or are we waiting for the api to be done first?
I think the hope/idea was to have both at once, but maybe we should re-consider
Metadata Update from @pingou: - Issue priority set to: Next Meeting (was: Waiting on Assignee)
So, I see our options here:
1) Go ahead and move pagure.io web logins to OIDC now, close this. 2) Keep waiting for ipsilon work to unblock the api move, close this 3) Just close this won't fix for now until 1 or 2 happens 4) something else.
Thoughts?
i'm
So, I see our options here: 1) Go ahead and move pagure.io web logins to OIDC now, close this. 2) Keep waiting for ipsilon work to unblock the api move, close this 3) Just close this won't fix for now until 1 or 2 happens 4) something else. Thoughts?
There has been no response from the initial reporter since this was reported, so going to implement 3)
closing as won't fix, and it can be reopen when 1) or 2) happens. (or if the original reporter wants it open still for some reason)
Metadata Update from @ryanlerch: - Issue close_status updated to: Will Not/Can Not fix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.