Skip to content
Snippets Groups Projects
  1. Jul 03, 2017
  2. Dec 05, 2016
    • Heikki Linnakangas's avatar
      Replace PostmasterRandom() with a stronger source, second attempt. · fe0a0b59
      Heikki Linnakangas authored
      This adds a new routine, pg_strong_random() for generating random bytes,
      for use in both frontend and backend. At the moment, it's only used in
      the backend, but the upcoming SCRAM authentication patches need strong
      random numbers in libpq as well.
      
      pg_strong_random() is based on, and replaces, the existing implementation
      in pgcrypto. It can acquire strong random numbers from a number of sources,
      depending on what's available:
      
      - OpenSSL RAND_bytes(), if built with OpenSSL
      - On Windows, the native cryptographic functions are used
      - /dev/urandom
      
      Unlike the current pgcrypto function, the source is chosen by configure.
      That makes it easier to test different implementations, and ensures that
      we don't accidentally fall back to a less secure implementation, if the
      primary source fails. All of those methods are quite reliable, it would be
      pretty surprising for them to fail, so we'd rather find out by failing
      hard.
      
      If no strong random source is available, we fall back to using erand48(),
      seeded from current timestamp, like PostmasterRandom() was. That isn't
      cryptographically secure, but allows us to still work on platforms that
      don't have any of the above stronger sources. Because it's not very secure,
      the built-in implementation is only used if explicitly requested with
      --disable-strong-random.
      
      This replaces the more complicated Fortuna algorithm we used to have in
      pgcrypto, which is unfortunate, but all modern platforms have /dev/urandom,
      so it doesn't seem worth the maintenance effort to keep that. pgcrypto
      functions that require strong random numbers will be disabled with
      --disable-strong-random.
      
      Original patch by Magnus Hagander, tons of further work by Michael Paquier
      and me.
      
      Discussion: https://www.postgresql.org/message-id/CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com
      Discussion: https://www.postgresql.org/message-id/CAB7nPqRWkNYRRPJA7-cF+LfroYV10pvjdz6GNvxk-Eee9FypKA@mail.gmail.com
      fe0a0b59
  3. May 18, 2015
    • Noah Misch's avatar
      pgcrypto: Report errant decryption as "Wrong key or corrupt data". · 85270ac7
      Noah Misch authored
      This has been the predominant outcome.  When the output of decrypting
      with a wrong key coincidentally resembled an OpenPGP packet header,
      pgcrypto could instead report "Corrupt data", "Not text data" or
      "Unsupported compression algorithm".  The distinct "Corrupt data"
      message added no value.  The latter two error messages misled when the
      decrypted payload also exhibited fundamental integrity problems.  Worse,
      error message variance in other systems has enabled cryptologic attacks;
      see RFC 4880 section "14. Security Considerations".  Whether these
      pgcrypto behaviors are likewise exploitable is unknown.
      
      In passing, document that pgcrypto does not resist side-channel attacks.
      Back-patch to 9.0 (all supported versions).
      
      Security: CVE-2015-3167
      85270ac7
  4. Nov 11, 2014
    • Tom Lane's avatar
      Loop when necessary in contrib/pgcrypto's pktreader_pull(). · f2ad2bdd
      Tom Lane authored
      This fixes a scenario in which pgp_sym_decrypt() failed with "Wrong key
      or corrupt data" on messages whose length is 6 less than a power of 2.
      
      Per bug #11905 from Connor Penhale.  Fix by Marko Tiikkaja, regression
      test case from Jeff Janes.
      f2ad2bdd
  5. Nov 22, 2009
    • Tom Lane's avatar
      Improve psql's tabular display of wrapped-around data by inserting markers · 1753337c
      Tom Lane authored
      in the formerly-always-blank columns just to left and right of the data.
      Different marking is used for a line break caused by a newline in the data
      than for a straight wraparound.  A newline break is signaled by a "+" in the
      right margin column in ASCII mode, or a carriage return arrow in UNICODE mode.
      Wraparound is signaled by a dot in the right margin as well as the following
      left margin in ASCII mode, or an ellipsis symbol in the same places in UNICODE
      mode.  "\pset linestyle old-ascii" is added to make the previous behavior
      available if anyone really wants it.
      
      In passing, this commit also cleans up a few regression test files that
      had unintended spacing differences from the current actual output.
      
      Roger Leigh, reviewed by Gabrielle Roth and other members of PDXPUG.
      1753337c
  6. Jul 10, 2005
Loading