Bug report #10517

Reading PGPASS fails on 64-Bit Version

Added by Brett Z over 10 years ago. Updated over 5 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Data Provider/PostGIS
Affected QGIS version:2.18.4 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:end of life
Crashes QGIS or corrupts data:No Copied to github as #:18927

Description

When attempting to connect to a PostGIS layer from QGIS, I get the following message (if using a password stored in pgpass.conf):

FATAL: password authentication failed for user "[username]"
password retrieved from file "C:\\Users[username]\\AppData\\Roaming/postgresql/pgpass.conf"

This error does not occur when the same pgpass file is used in the 32-bit version of QGIS. This issue seems to occur in QGIS 2.0 - 2.3 on Windows 7 and 8.1. I have also found I can work-around this issue by only having a single entry on a single line (with no return at the end) in pgpass. For example, a pgpass with two entries will fail in the 64-bit QGIS, but work fine in the 32-bit QGIS; however single entry pgpass files work fine in both versions (provided there is no return at the end of the single line).

History

#1 Updated by Jürgen Fischer over 10 years ago

  • Category set to Data Provider/PostGIS
  • Resolution set to up/downstream

#2 Updated by Giovanni Manghi over 10 years ago

should this be closed?

#3 Updated by Brett Z over 10 years ago

The issue is certainly frustrating, as anyone using pgadmin would likely have more than one entry in pgpass (we'll likely move back to 32-bit). However, if there's nothing that can be done about it on the QGIS end, it may be closed. Thank you for investigating it.

#4 Updated by Giovanni Manghi over 10 years ago

  • Status changed from Open to Closed

Brett Z wrote:

The issue is certainly frustrating, as anyone using pgadmin would likely have more than one entry in pgpass (we'll likely move back to 32-bit). However, if there's nothing that can be done about it on the QGIS end, it may be closed. Thank you for investigating it.

so as far as I understand does not affect only qgis, but also pgadmin (for example), right?

#5 Updated by Brett Z over 10 years ago

I've only experienced this problem in QGIS, not pgAdmin; however, that's likely because pgAdmin is 32 bit. The issue does not occur in 32-bit QGIS, only 64 bit.

#6 Updated by Martin HOFFMANN about 9 years ago

  • Target version changed from Version 2.4 to Version 2.10
  • Status changed from Closed to Reopened

I propose to reopen since I've found the culprit. I also provide an updated workaround for those who encounter the same problem.
I confirm this occur also under Windows 10.

The problem is solely caused by the EOL (End Of Line) encoding of this file:

C:\\Users\\username\\AppData\\Roaming\\postgresql\\pgpass.conf

This file is "shared" between PgAdmin and QGis but the two programs don't use the same EOL when accessing this file.
PgAdmin still write Windows Style (CR/LF) but Qgis 64-bit seem to be lost with (CR) and recognize only Unix style (LF). However PgAdmin can handle Unix style (LF)-only and keep the file untouched while reading.

So if you need to use both PgAdmin and Qgis on a Windows7+ just convert EOL to (LF)-only in "pgpass.conf" using a suitable Text Editor (Notepad++ for instance). Unlike previous workaround this will work fine with multiple lines hence multiple entries in pgpass.conf.

Unfortunately you will need to convert this file again every time PgAdmin happen to update the file.

I reopen the issue as it think it would be a pretty minor work to ask Qgis 64-bit to also handle the (CR/LF) EOL when running under windows. This should have zero side effect as no-one in his right mind will use a (CR) EOL inside a password...

I might be wrong however, feel free to close again, at least a better workaround is now provided ;)

PS: On a side note i don't get why this file is actually parsed because it seems that Qgis also store connection somewhere else.Password saved through the PostgisConnection manager are not wrote in the same file. So is that some sort of legacy mode?

Thanks a lot for reading this boring follow-up ;)

#7 Updated by Jürgen Fischer about 9 years ago

Martin HOFFMANN wrote:

I reopen the issue as it think it would be a pretty minor work to ask Qgis 64-bit to also handle the (CR/LF) EOL when running under windows. This should have zero side effect as no-one in his right mind will use a (CR) EOL inside a password...

PS: On a side note i don't get why this file is actually parsed because it seems that Qgis also store connection somewhere else.Password saved through the PostgisConnection manager are not wrote in the same file. So is that some sort of legacy mode?

QGIS doesn't read or write that file at all. libpq does.

#8 Updated by Martin HOFFMANN about 9 years ago

So when you install both PgAdmin and QGis (via OSGeow4w) you end up with 2 different version of libpq.
This seems unavoidable and none of the project are "at fault". This issue might resolve by itself when PgAdmin will switch to a more recent libpq version.

I guess we can close again and the next person that will stumble here can use this as the best workaround

So if you need to use both PgAdmin and Qgis on a Windows7+ just convert EOL to (LF)-only in "pgpass.conf" using a suitable Text Editor (Notepad++ for instance). Unlike previous workaround this will work fine with multiple lines hence multiple entries in pgpass.conf

Unfortunately you will need to convert this file again every time PgAdmin happen to update the file.

I feel like I reopened too quickly, sorry about that. So are you ok to close?

#9 Updated by Martin HOFFMANN about 9 years ago

  • Status changed from Reopened to Closed

No responses, so I guess it's safe to close again.

#10 Updated by Jérôme Guélat over 7 years ago

  • Status changed from Closed to Reopened
  • Target version changed from Version 2.10 to Version 2.18

I tested this issue with 2.18.4 and 2.14.12 and I'm also having problems, even when using only LF EOL... QGIS is extracting the login/password information only for one connection (it doesn't have to be the first one in the pgpass file), but it doesn't work for the other ones. Interestingly the connection that is working is a 9.6 server, and all the other are servers with version 9.5 or lower.

The same pgpass file works perfectly when connecting with pgAdmin or with the RPostgreSQL package in R.

#11 Updated by Giovanni Manghi over 7 years ago

  • Affected QGIS version changed from 2.0.1 to 2.18.4
  • Resolution deleted (up/downstream)

#12 Updated by Giovanni Manghi over 7 years ago

  • Easy fix? set to No
  • Regression? set to No

#13 Updated by olivier olivier over 6 years ago

Hi, I found that converting 0d 0a to 0a 0d (with software such as hex editor neo) works for pgadmin and qgis.

Olivier

#14 Updated by Giovanni Manghi over 5 years ago

  • Status changed from Reopened to Closed
  • Resolution set to end of life

End of life notice: QGIS 2.18 LTR

Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/

QGIS 3.4 has recently become our new Long Term Release (LTR) version. This is a major step in our history – a long term release version based on the massive updates, library upgrades and improvements that we carried out in the course of the 2.x to 3x upgrade cycle.

We strongly encourage all users who are currently using QGIS 2.18 LTR as their preferred QGIS release to migrate to QGIS 3.4. This new LTR version will receive regular bugfixes for at least one year. It also includes hundreds of new functions, usability improvements, bugfixes, and other goodies. See the relevant changelogs for a good sampling of all the new features that have gone into version 3.4

Most plugins have been either migrated or incorporated into the core QGIS code base.

We strongly discourage the continued use of QGIS 2.18 LTR as it is now officially unsupported, which means we’ll not provide any bug fix releases for it.

You should also note that we intend to close all bug tickets referring to the now obsolete LTR version. Original reporters will receive a notification of the ticket closure and are encouraged to check whether the issue persists in the new LTR, in which case they should reopen the ticket.

If you would like to better understand the QGIS release roadmap, check out our roadmap page! It outlines the schedule for upcoming releases and will help you plan your deployment of QGIS into an operational environment.

The development of QGIS 3.4 LTR has been made possible by the work of hundreds of volunteers, by the investments of companies, professionals, and administrations, and by continuous donations and financial support from many of you. We sincerely thank you all and encourage you to collaborate and support the project even more, for the long term improvement and sustainability of the QGIS project.

Also available in: Atom PDF