After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 693391 - Remember product keys
Remember product keys
Status: RESOLVED FIXED
Product: gnome-boxes
Classification: Applications
Component: wizard
3.7.x
Other Linux
: Normal normal
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-02-08 02:33 UTC by Zeeshan Ali
Modified: 2016-03-31 13:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
unattended-setup-box: Take media as constructor arg (2.18 KB, patch)
2015-02-26 23:38 UTC, Zeeshan Ali
committed Details | Review
unattended-setup-box: Cache setup data (5.27 KB, patch)
2015-02-26 23:38 UTC, Zeeshan Ali
committed Details | Review

Description Zeeshan Ali 2013-02-08 02:33:19 UTC
It gets pretty frustrating to having to enter product keys all the time, even if copy&pasted from some file. It would be nice to cache the product key first time user enters it and automatically set it into the product key text entry for the user on subsequent runs. Ideally, we should keep separate cache for each ISO but having just one key cached at a time won't be a bad start either.
Comment 1 Christophe Fergeau 2013-02-08 09:18:34 UTC
Different Windows editions need different keys (winxp home VS winxp pro), so this per-ISO would work better than just one key (ideally this would be per OS version, but libosinfo does not have such a concept yet).
Comment 2 Zeeshan Ali 2013-02-08 14:34:55 UTC
(In reply to comment #1)
> Different Windows editions need different keys (winxp home VS winxp pro), so
> this per-ISO would work better than just one key (ideally this would be per OS
> version, but libosinfo does not have such a concept yet).

ack
Comment 3 Aldo Román 2013-03-30 07:05:22 UTC
The per-ISO means that having a different ISO for the same OS does not recognize it?

I would think of a list containing the last used keys with its respective OS and version. On installation process, maybe filtering them by publisher would be useful (i.e. do not display Mac keys when installing Windows)
Comment 4 Zeeshan Ali 2013-03-30 19:57:01 UTC
(In reply to comment #3)
> The per-ISO means that having a different ISO for the same OS does not
> recognize it?

I don't think people typically keep multiple duplicate ISOs and when they do, I don't think it would be a big deal if they have to type the key twice rather than once.

> I would think of a list containing the last used keys with its respective OS
> and version. On installation process, maybe filtering them by publisher would
> be useful (i.e. do not display Mac keys when installing Windows)

I don't see the need to go that far. The point is to making users life easier and not make them having to write the key each time they create a VM against a particular installer.
Comment 5 Zeeshan Ali 2015-02-26 23:38:27 UTC
Created attachment 298050 [details] [review]
unattended-setup-box: Take media as constructor arg

Instead of passing different parts of the InstallerMedia instance, lets
pass the instance itself to constructor and let it take what it needs
from it.
Comment 6 Zeeshan Ali 2015-02-26 23:38:34 UTC
Created attachment 298051 [details] [review]
unattended-setup-box: Cache setup data

Cache express install toggle, username, password and product key for
every media. No need to keep product keys in a separate file and having
to paste them each time you create a windows VM anymore. \o/
Comment 7 Matthias Clasen 2015-02-27 00:20:16 UTC
Where does this data get stored, and will users know how to clear it ?
Comment 8 Zeeshan Ali 2015-02-27 00:29:12 UTC
(In reply to Matthias Clasen from comment #7)
> Where does this data get stored,

~/.cache/gnome-boxes/unattended/setup-data.conf

> and will users know how to clear it ?

I wouldn't know how to expose such an option nicely. I think its ok for now if they currently have to remove that hidden file.
Comment 9 André Klapper 2015-02-27 09:10:01 UTC
(In reply to Zeeshan Ali (Khattak) from comment #8)
> > and will users know how to clear it ?
> 
> I wouldn't know how to expose such an option nicely. I think its ok for now
> if they currently have to remove that hidden file.

Is that a common action? = Should it be covered in docs?
Comment 10 Zeeshan Ali 2015-02-27 12:50:56 UTC
(In reply to André Klapper from comment #9)
> (In reply to Zeeshan Ali (Khattak) from comment #8)
> > > and will users know how to clear it ?
> > 
> > I wouldn't know how to expose such an option nicely. I think its ok for now
> > if they currently have to remove that hidden file.
> 
> Is that a common action? = Should it be covered in docs?

I seriously doubt so.
Comment 11 Matthias Clasen 2015-02-27 15:38:53 UTC
sorry, didn't mean to derail this.
having it stored in ~/.cache is fine
Comment 12 Zeeshan Ali 2015-03-02 14:01:07 UTC
Attachment 298050 [details] pushed as d806ef5 - unattended-setup-box: Take media as constructor arg
Attachment 298051 [details] pushed as ae21e56 - unattended-setup-box: Cache setup data