I don't think encryption is important enough for v1. Add a warning saying that you should do this either over ssl or on an internal network. Make a ticket to encrypt both transfer and disk for us to work on for a later project. (and maybe even add a note to projects.openmrs.org so we don't forget it)
Ben On Tue, Nov 8, 2011 at 9:11 AM, Darius Jazayeri <[email protected]>wrote: > For #4, I meant that the user shouldn't have to (or be allowed to) set the > database properties (connection/driver/user/pass), because those should be > pre-determined by the standalone that's containing the app. > > For #8, a progress bar is fine, though I'd add that in v2. :-) > > I was actually talking about encrypting the sqldump in case we have to > write it to disk in /tmp for some reason, keeping the key in memory for the > runtime of the install wizard. We might as well also encrypt over the wire > if we're doing that. (Though if you're not using SSL, you'll have to pass > the secret key over the wire unencrypted, so it doesn't actually prevent a > targeted attack.) > > -Darius > > > On Mon, Nov 7, 2011 at 6:59 PM, Burke Mamlin <[email protected]>wrote: > >> Sounds good. Pretty similar to what I was thinking. >> >> Is #4 (Install wizard should not ask you the typical series of questions >> about db connect string, user/pass, root user/pass. Instead the standalone >> should have set these to fixed values) because all the credentials on the >> production system will be transferred? We're not suggesting that we'd have >> fixed username/password for the test system containing production data, are >> we? >> >> For #8, regarding "the user doesn't see this happening", how about a >> progress bar in case the production system, the connection to it, or the >> data transfer is slow? >> >> As far as encrypting the data being transferred, this would be great as >> long as it can be done relatively easily, since it will be production data. >> How about having the standalone generate a long (e.g., 1024-character) >> random string, passing it to the production server, and then using that >> string to encrypt & decrypt the data. That way, the key would only exist >> in the memory of the standalone while it was transferring the data. >> >> Cheers, >> >> -Burke >> >> On Mon, Nov 7, 2011 at 9:22 PM, Darius Jazayeri <[email protected]>wrote: >> >>> Wyclif and I discussed on IRC, and came up with this: >>> >>> 1. User downloads standalone, unzips, and double clicks on the JAR >>> 2. User chooses a "show me install wizard" option (needs a ticket) >>> 3. Install wizard asks (a) Standard, (b) Custom, (c) Test an upgrade >>> (requires uncommenting some code that already exists). User chooses (c). >>> 4. Install wizard should *not* ask you the typical series of >>> questions about db connect string, user/pass, root user/pass. Instead the >>> standalone should have set these to fixed values. >>> 5. Install wizard asks for the URL of the production server you want >>> to test an upgrade for. >>> 6. Test server verifies that the production server is reachable at >>> that URL, and that it's running the Release Testing module. If either >>> check >>> fails, give an appropriate error message, and return to the previous >>> step. >>> 7. Test server asks user for username/password for the production >>> server, and verifies that they're valid. If not, ask again. >>> 8. Test server uses those credentials to fetch an appropriate sql >>> dump, and zip file of modules. (It does this server-side, the user >>> doesn't >>> see this happening. To do: decide whether we need to encrypt the sqldump >>> we >>> write to a temp directory, or if the Release Testing module should >>> de-identify it as it outputs it.) >>> 9. Install wizard loads up the sql dump, and puts the modules in the >>> right place. >>> 10. Install wizard runs the liquibase update scripts >>> 11. Finally, a login screen! >>> >>> -Darius >>> >>> On Mon, Nov 7, 2011 at 5:42 PM, Darius Jazayeri <[email protected]>wrote: >>> >>>> Hi Wyclif, >>>> >>>> I was wondering if you could give a step-by-step overview of the >>>> process you're envisioning as our target from this sprint. >>>> >>>> 1. User downloads standalone 1.9-beta, unzips it, and double clicks on >>>> the JAR >>>> ...(what happens here)... >>>> N. User sees a login window to a standalone instance whose DB is >>>> populated with data from an existing install. >>>> >>>> -Darius >>>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
