OpenEMR 4.1.2

OpenEMR Development
1

bradymiller wrote on Thursday, June 13, 2013:

Hi,

Probably about time to begin thinking about the new release. Only loose end to tie up is the password stuff on windows, then I think we would be ready to branch for a release goal of early August.

Thoughts?

-brady
OpenEMR

2

fsgl wrote on Thursday, June 13, 2013:

Hello Brady,

What new features and improvements can we expect?

3

arnabnaha wrote on Thursday, June 13, 2013:

Really looking forward for the release and hope to get the xampp thing fixed soon too…

4

blankev wrote on Thursday, June 13, 2013:

Before launching the new version can you activate the translators again a couple of times so they can just give another extra for translations.

I like the mail with total percentage of translated definitions for each language.

5

sunsetsystems wrote on Thursday, June 13, 2013:

Early August sounds good to me.

Rod
http://www.sunsetsystems.com/

6

tmccormi wrote on Friday, June 14, 2013:

Past due in my opinion. :slight_smile: Let’s rock!

Tony McCormick, CTO
Medical Information Integration, LLC

@MI2_OpenEMR

On Wed, Jun 12, 2013 at 9:36 PM, Brady Miller bradymiller@users.sf.netwrote:

Hi,

Probably about time to begin thinking about the new release. Only loose
end to tie up is the password stuff on windows, then I think we would be
ready to branch for a release goal of early August.

Thoughts?

-brady
OpenEMR http://www.open-emr.org/

OpenEMR 4.1.2https://sourceforge.net/p/openemr/discussion/202506/thread/a415cf97/?limit=25#7b73

Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / Developers

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

7

yehster wrote on Friday, June 14, 2013:

Another issue with the security changes is that they break the dynamic finder’s ability to “Open in New Window.”


The code here exploits the pass the hash security issue we intended to address.

I am unsure of a reasonable solution.

8

bradymiller wrote on Saturday, June 15, 2013:

Hi,
Storing of the authpass in a session variable doesn’t feel right anyways. Here’s a grep of authpass:

/var/www/openemr/library/authentication/login_operations.php:            $_SESSION['authPass'] = $phash;
/var/www/openemr/login.php:<input type="hidden" name="authPass">
/var/www/openemr/login.php:<input type="submit" onClick="javascript:this.form.authPass.value=SHA1(this.form.clearPass.value);this.form.clearPass.value='';" value="<?php xl('Login','e'); ?>">
/var/www/openemr/myportal/soap_service/server_side.php:                 $authPass=$var['authPass'];
/var/www/openemr/myportal/soap_service/server_side.php:                 sqlInsert($query,array($pid,$username,$authPass));
/var/www/openemr/interface/usergroup/user_admin.php:  if ($_GET["newauthPass"] && $_GET["newauthPass"] != "d41d8cd98f00b204e9800998ecf8427e") { // account for empty
/var/www/openemr/interface/usergroup/user_admin.php:    $tqvar = formData('newauthPass','G');
/var/www/openemr/interface/usergroup/usergroup_admin_add.php:<input type="hidden" name="newauthPass">
/var/www/openemr/interface/main/finder/dynamic_finder.php:<input type='hidden' name='authPass'       value='<?php echo attr($_SESSION['authPass']);        ?>' />
grep: /var/www/openemr/interface/main/calendar/modules/PostCalendar/pntemplates/compiled/%%154: Permission denied
grep: /var/www/openemr/interface/main/calendar/modules/PostCalendar/pntemplates/compiled/%%164: Permission denied
grep: /var/www/openemr/interface/main/calendar/modules/PostCalendar/pntemplates/compiled/%%514: Permission denied
/var/www/openemr/Documentation/OpenEMR_Backend_Spec.txt:        $_SESSION['authPass'] = md5sum of logged in users password

Should we just yank this session variable? It’s not gonna work anyways and another way will be needed to do this (the feature of opening it up in a new window will basically no longer be supported until a new mechanism is added).

-brady
OpenEMR

9

bradymiller wrote on Saturday, June 15, 2013:

Additionally,
Guessing the new solution to make this work will lie within this function:
http://php.net/manual/en/function.session-regenerate-id.php
-brady
OpenEMR

10

bradymiller wrote on Saturday, June 15, 2013:

Hi,

Here are some initial wiki pages on the release process etc. Goal is to have this release be more of a group effort. Plan to create the branch once a translation iteration (and the login stuff) is complete. At that point, can then create the branch demos.

http://www.open-emr.org/wiki/index.php/Steps_for_an_official_release
http://www.open-emr.org/wiki/index.php/QA/Release_Process#Version_4.1.2

-brady
OpenEMR

11

yehster wrote on Saturday, June 15, 2013:

Yes, I agree that it’s a good idea to yank authPass.

12

yehster wrote on Saturday, June 15, 2013:

The impact of the security changes on the offsite portal aren’t really known either. However since it’s a closed source app I feel justified in leaving the responsibility for testing to ZHH.

13

yehster wrote on Tuesday, June 25, 2013:

It might also be nice to come to a decision about either removing or upgrading PHPMyAdmin for the release.

14

bradymiller wrote on Tuesday, June 25, 2013:

Hi,

Still think the phpMyAdmin debate is going on. Either should:

  1. Remove it (and then provide a mechanism within OpenEMR to import new translation tables, since this is a common thing done by international users, which make up the majority of the OpenEMR downloads : http://www.open-emr.org/wiki/index.php/Install_Translations )
  2. Upgrade it
  3. Leave it be

Since nobody is willing to likely spend time on it, looks like we are stuck on 3…

-brady
OpenEMR

15

tmccormi wrote on Tuesday, June 25, 2013:

Why do we need to provide a different way to import the tables? Xampp has
external copy of phpmyadmin and Linux users can install it easily. It’s the
redundant Imbedded copy that is unneeded, out of date and customized,
therefore a pain to maintain.

Could even have the menu link configured to run it if it’s installed and
require entry of correct db or root user/password. Safer that way.

Tony

On Jun 25, 2013 1:07 AM, “Brady Miller” bradymiller@users.sf.net wrote:

Hi,

Still think the phpMyAdmin debate is going on. Either should:

  1. Remove it (and then provide a mechanism within OpenEMR to import new
    translation tables, since this is a common thing done by international
    users, which make up the majority of the OpenEMR downloads :
    Install Translations - OpenEMR Project Wiki )
  2. Upgrade it
  3. Leave it be

Since nobody is willing to likely spend time on it, looks like we are
stuck on 3…

-brady
OpenEMR http://www.open-emr.org/

OpenEMR 4.1.2https://sourceforge.net/p/openemr/discussion/202506/thread/a415cf97/?limit=25#c62f

Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / Developers

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

16

yehster wrote on Tuesday, June 25, 2013:

The instructions for importing translations could be changed to use mysql from the command line instead of PHPMyAdmin.

17

yehster wrote on Wednesday, June 26, 2013:

http://cwe.mitre.org/top25/index.html#CWE-250
Preventing “execution with unnecessary privileges” is one of many reasons why including PHPMyadmin is a bad idea.
It is also the rationale behind the privDb mechanism I added. I think this link explains the concept better than my write up.

18

bradymiller wrote on Friday, June 28, 2013:

Hi,

Upgraded it to phpmyadmin 4.0.4 (most current productions release). Here is the branch:

To be clear, I did it in 4 different commits(see the branch):
Commit 1: Removed old phpmyadmin
Commit 2: Unzipped phpmyadmin 4.0.4 (All Languages Version) without any modifications
Commit 3: Integrated it into OpenEMR with some minor work
Commit 4: Fixed a bug in acl.inc library, so now users besides ‘admin’ can use phpmyadmin (there were scope issues, surprised we weren’t getting bug reports on this…)

Thoughts here? This is a very frequently used tool by DIY and international users. At this point all I have heard from professionals and vendors via forum posts and private email is how we should simply remove this tool, which are then followed by proposals (ie. no work, just talk) on how to the fill the gap. We can always recommend users to remove on the wiki Security page if users need to harden their security on the wiki Security page, which all instruction manuals point to.

Also want to separate two issues here.

  1. One is security. There is a reasonable argument here that including any scripts into the codebase (such as phpmyadmin) does bring in potential for security vulnerabilities (which is why it is very reasonable to recommend removing this on the Security wiki page for users whom need to harden their instance).
  2. One is limiting the autonomony of the user. Meaning, the argument of removing tools so the (usually new) user isn’t able to do some really damaging things. With this argument, we might as well then yank all of the Administration->Lists from plain sight since messing with these can break OpenEMR and degrade the patient data.

-brady
OpenEMR

19

bradymiller wrote on Saturday, June 29, 2013:

There is some discussion on the above post here:
http://sourceforge.net/p/openemr/discussion/202506/thread/8dd32916/

20

bradymiller wrote on Sunday, June 30, 2013:

Hi,

Looked over the “Open in New Window.” issue (Patient/Client->Patients search screen) and I think I have come up with a solution that seems to work. I tried to deal with it at the session level, but found it impossible to separate/clone sessions. So, attacked it as Rod did originally by doing a “authentication” to get a new instance of OpenEMR. Basically, the screen collects a temporary authentication token id and then uses this to log in. The code is pretty straightforward and placed a bunch of safeguards in place to ensure the tokens do not linger at all (note they are also hashed so can not “pass-the-token” attack); even utilized a very cool mechanism that OpenEMR has (background-services module) to wipe out any tokens that are lying around in the background. Here is the code:

I realize this is not a slam dunk commit, since it does complicate authentication code a bit more. But, if strategy is acceptable, would like to get into 4.1.2. (the feature of being able to open different patient records and work in them concurrently is very useful)

At this point, once this is in and the new phpmyadmin verson is in, plan to branch the code for v4.1.2 and create the demo vehicles/downloads (goal is to do this sometime in the next week). Then will leave about 4 more weeks of testing and bug fixes until the official release.

-brady
OpenEMR