[rfc][icedtea-web] remove redundnat declaration of changeit

Jie Kang jkang at redhat.com
Wed Apr 15 13:17:35 UTC 2015


Hi,

Looking at the repo a lot of this got pushed..; Is there anything left for review?


Regards,

----- Original Message -----
> On 04/03/2015 04:22 PM, Jiri Vanek wrote:
> > So here is last part.
> >
> 
> Update - previous impl had possible bug - under some circumstances, it was
> possible to write to
> keystore by null password, and so break the integrity of keystore (it just
> never asked for apssword
> again)
> 
> After thsi changset this rare condition shoudl not bee possible.
> 
> Also I refactored code a bit .
> 
> J.
> >
> > When it fails to decode keystore, it asks user. If user will enter password
> > which actually unlocks
> > something, it will not ask him for this password again (so it asks only
> > once)
> >
> > The patch works prety nice considering how user friendly refactoring is in
> > public code, and how
> > small logic was added into private one ( O:) )
> >
> > How to test
> >
> > backup ~/.config/icedtea-web/security/trusted.certs (or any valid
> > XDG_CONFIG variant)
> > then change password of it:
> > keytool -storepasswd -new newpass  -keystore trusted.certs
> >
> > Now run itweb-settings and ook into certificates->user->trusted
> > certificates
> >
> > On patched version it will prompt you for password (once (if you know
> > correct pasword)for all
> > operations). If you press cancel, it will justshow blank tab as without an
> > patch.
> >
> > Run
> >
> > javaws  -Xnofork http://www.geogebra.org/webstart/geogebra.jnlp
> >
> > During startup it will ask you for password (on new version)
> > If you press cancel it will ask you even one more times.
> > Look how different is behaves! (aka showing/not  showing warning dialogue,
> > or prompting on save if
> > you  "trust always" and so on.)
> >
> > Revert your keystore, once you are done :)
> >
> > known bugs - the password is normally visible on screen. It can be fixed in
> > next changeset.
> >
> >
> > J.!
> >
> > On 04/02/2015 02:16 PM, Jiri Vanek wrote:
> >> On 04/02/2015 10:25 AM, Jiri Vanek wrote:
> >>> On 04/02/2015 03:04 AM, Jacob Wisor wrote:
> >>>> Am 01.04.2015 um 17:40 schrieb Jiri Vanek:
> >>>>> Hello!
> >>>>>
> >>>>> Today Ihad spotted quite serious bug, and I'm wondering no one ever
> >>>>> compalined.
> >>>>
> >>>> I have spotted it too but I did not complain because I have learned that
> >>>> IcedTea-Web is full of
> >>>> such
> >>>> bugs.
> >>>>
> >>>>> ITW is not able to work with custom password on keystores.
> >>>>> This patch is just small clean  up before actual work.
> >>>>
> >>>> Well, I have prepared a far more elaborate patch than this one. The
> >>>> problems here are far deeper
> >>> [1]
> >>>> reaching than this patch addresses. I'd rather say we should not make
> >>>> any quick shots now and
> >>>
> >>> Still this is good thing to do....
> >>>> postpone pushing it until after the release of 1.6.
> >>>
> >>> ..and even for 1.6
> >>>>
> >>>> As you say, this is a preparatory patch, so you can keep on working
> >>>> based on this patch and then
> >>>
> >>> I'm already doing so. But it do not block to push it.
> >>>
> >>>> push a set of patches so that we will have a nice history of
> >>>> sequentially dependent patches
> >>>> (changesets, speaking in Mercurial).
> >>>
> >>> And this is refactoring. So it is definitive worthy to push ahead.
> >>>
> >>>
> >>> j.
> >>>
> >>> [1]
> >>>
> >>> The patch I'm doing for this is not so complex.
> >>>
> >>> It  wraps all various calls to keyStore.something(password) by utility
> >>> method, which tries default
> >>> password  if it do not work and is not-headless then asks user. Even
> >>> several times.
> >>>
> >>> Small question is, whether to save this password ( I'm +1 to save it as
> >>> char[])  until java closes.
> >>>
> >>> Then those passwords will be tried before asking user again.
> >>>
> >>> Unless you see something wrong with this patch (" remove redundnat
> >>> declaration of changeit")  only,
> >>> I really would like to push rather then keep it locally. Maybe for ever.
> >>>
> >>>
> >>> J.
> >>
> >> Well, maybe you are right :)
> >>
> >> Here is second part. And yes.. it really maybe better to merge it with
> >> original patch.
> >>
> >> The next step  will be  to move all real work methods to single one, which
> >> will attempt password,
> >> and if invalid, then asl user, if again invalid then ask user untilhe gave
> >> up. If he put valid
> >> password, thenthis apsword will be saved, and used in any other iteration
> >> above keystres - if all
> >> stored passwords fails (including changeit) then user again will be
> >> prompted (will not beprompted in
> >> headless mode)
> >>
> >> Thoughts?
> >>
> >>   j.
> >
> 
> 

-- 

Jie Kang

OpenJDK Team - Software Engineering Intern


More information about the distro-pkg-dev mailing list