duply (simple duplicity) / Bugs / #101 Duply does not check if GPG_AGENT

ede - 2016-10-18

On 18.10.2016 00:54, Thomas Harning Jr. wrote:

[bugs:#101] https://sourceforge.net/p/ftplicity/bugs/101/ Duply does not check if GPG_AGENT_INFO is 'bogus'

Status: open
Group: duply
Labels: patch gpg
Created: Mon Oct 17, 2016 10:54 PM UTC by Thomas Harning Jr.
Last Updated: Mon Oct 17, 2016 10:54 PM UTC
Owner: ede

If GPG_AGENT_INFO is setup by the default Xinit scripts as they are in Ubuntu, then the value will be invalid.
See: https://wiki.debian.org/Teams/GnuPG/UsingGnuPGv2 for documentation about this.
They set PID to 0 (since they don't know the running daemon's PID) and send things along.

Upstream suggests calling out to the agent to check on the agent, but the suggested method there (https://lists.gnupg.org/pipermail/gnupg-devel/2015-March/029601.html) creates an agent (not sure if that's desired or not).

A mechanism that seems to be a sure-fire fix that should be GPG 2.0 compatible is to simply connect to the agent via gpg-agent to verify connectivity, however we lose out on details about stale PID environment.

Inlined patch to check if the PID is zero and skips the PID sanity check in that case.
SNIP

did your runtime verify both of your patches? ..ede/duply.net

Related

Bugs: ~~#101~~

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thomas Harning Jr. - 2016-10-18

I have fully tested both patches with GnuPG 2.1.x (2.1.11 and 2.1.12) and have done a quick test on GnuPG 2.0.x (2.0.30) to see that gpg-agent behaves properly in the case of:

Agent running but no environment (GnuPG 2.0.x expected the environment variable present) - failed indicating no gpg-agent running in this session

Agent running with environment - found it

Agent not running with environment from old - IPC connect call failed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- ede - 2016-10-18
  
  that should suffice :).. thanks! ede
  
  On 18.10.2016 16:46, Thomas Harning Jr. wrote:
  
  I have fully tested both patches with GnuPG 2.1.x (2.1.11 and 2.1.12) and have done a quick test on GnuPG 2.0.x (2.0.30) to see that gpg-agent behaves properly in the case of:
  
  Agent running but no environment (GnuPG 2.0.x expected the environment variable present) - failed indicating no gpg-agent running in this session
  
  Agent running with environment - found it
  
  Agent not running with environment from old - IPC connect call failed
  
  [bugs:#101] https://sourceforge.net/p/ftplicity/bugs/101/ Duply does not check if GPG_AGENT_INFO is 'bogus'
  
  Status: open
  Group: duply
  Labels: patch gpg
  Created: Mon Oct 17, 2016 10:54 PM UTC by Thomas Harning Jr.
  Last Updated: Mon Oct 17, 2016 10:54 PM UTC
  Owner: ede
  
  If GPG_AGENT_INFO is setup by the default Xinit scripts as they are in Ubuntu, then the value will be invalid.
  See: https://wiki.debian.org/Teams/GnuPG/UsingGnuPGv2 for documentation about this.
  They set PID to 0 (since they don't know the running daemon's PID) and send things along.
  
  Upstream suggests calling out to the agent to check on the agent, but the suggested method there (https://lists.gnupg.org/pipermail/gnupg-devel/2015-March/029601.html) creates an agent (not sure if that's desired or not).
  
  A mechanism that seems to be a sure-fire fix that should be GPG 2.0 compatible is to simply connect to the agent via gpg-agent to verify connectivity, however we lose out on details about stale PID environment.
  
  Inlined patch to check if the PID is zero and skips the PID sanity check in that case.
  
  @@ -1563,9 +1563,15 @@ function gpg_pass_pipein {
  function gpg_agent_avail {
  local ERR=1
  if var_isset GPG_AGENT_INFO; then
  - ps -p $(echo $GPG_AGENT_INFO|awk -F: '{print $2}') > /dev/null 2>&1 && \
  - ERR=0 || ERR=2
  - else
  + local GPG_AGENT_PID=$(echo $GPG_AGENT_INFO|awk -F: '{print $2}')
  + if [ "$GPG_AGENT_PID" != "0" ]; then
  + ps -p "$GPG_AGENT_PID" > /dev/null 2>&1 && \
  + ERR=0 || ERR=2
  + fi
  + fi
  + # If we know that the PID isn't stale, try to connect to an agent
  + # - we could skip to this, but we wouldn't be told about stale environment variables
  + if [ "$ERR" -ne "2" ]; then
  # GPG_AGENT_INFO is deprecated in gpg2.1,
  # so we try to connect to a possibly running agent here
  gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
  
  A different patch that /just/ checks connectivity via gpg-agent.
  
  @@ -1562,14 +1562,8 @@ function gpg_pass_pipein {
  # 3 cannot connect to gpg-agent
  function gpg_agent_avail {
  local ERR=1
  - if var_isset GPG_AGENT_INFO; then
  - ps -p $(echo $GPG_AGENT_INFO|awk -F: '{print $2}') > /dev/null 2>&1 && \
  - ERR=0 || ERR=2
  - else
  - # GPG_AGENT_INFO is deprecated in gpg2.1,
  - # so we try to connect to a possibly running agent here
  - gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
  - fi
  + # Try to connect to a possibly running agent here
  + gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
  
  return $ERR
  }
  
  Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ftplicity/bugs/101/
  
  To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Bugs: ~~#101~~
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- ede - 2016-10-18
  
  wouldn't the preset GPG_AGENT_INFO with the pid 0 not warrant a stale error message as well?
  
  ..ede
  
  On 18.10.2016 16:46, Thomas Harning Jr. wrote:
  
  I have fully tested both patches with GnuPG 2.1.x (2.1.11 and 2.1.12) and have done a quick test on GnuPG 2.0.x (2.0.30) to see that gpg-agent behaves properly in the case of:
  
  Agent running but no environment (GnuPG 2.0.x expected the environment variable present) - failed indicating no gpg-agent running in this session
  
  Agent running with environment - found it
  
  Agent not running with environment from old - IPC connect call failed
  
  [bugs:#101] https://sourceforge.net/p/ftplicity/bugs/101/ Duply does not check if GPG_AGENT_INFO is 'bogus'
  
  Status: open
  Group: duply
  Labels: patch gpg
  Created: Mon Oct 17, 2016 10:54 PM UTC by Thomas Harning Jr.
  Last Updated: Mon Oct 17, 2016 10:54 PM UTC
  Owner: ede
  
  If GPG_AGENT_INFO is setup by the default Xinit scripts as they are in Ubuntu, then the value will be invalid.
  See: https://wiki.debian.org/Teams/GnuPG/UsingGnuPGv2 for documentation about this.
  They set PID to 0 (since they don't know the running daemon's PID) and send things along.
  
  Upstream suggests calling out to the agent to check on the agent, but the suggested method there (https://lists.gnupg.org/pipermail/gnupg-devel/2015-March/029601.html) creates an agent (not sure if that's desired or not).
  
  A mechanism that seems to be a sure-fire fix that should be GPG 2.0 compatible is to simply connect to the agent via gpg-agent to verify connectivity, however we lose out on details about stale PID environment.
  
  Inlined patch to check if the PID is zero and skips the PID sanity check in that case.
  
  @@ -1563,9 +1563,15 @@ function gpg_pass_pipein {
  function gpg_agent_avail {
  local ERR=1
  if var_isset GPG_AGENT_INFO; then
  - ps -p $(echo $GPG_AGENT_INFO|awk -F: '{print $2}') > /dev/null 2>&1 && \
  - ERR=0 || ERR=2
  - else
  + local GPG_AGENT_PID=$(echo $GPG_AGENT_INFO|awk -F: '{print $2}')
  + if [ "$GPG_AGENT_PID" != "0" ]; then
  + ps -p "$GPG_AGENT_PID" > /dev/null 2>&1 && \
  + ERR=0 || ERR=2
  + fi
  + fi
  + # If we know that the PID isn't stale, try to connect to an agent
  + # - we could skip to this, but we wouldn't be told about stale environment variables
  + if [ "$ERR" -ne "2" ]; then
  # GPG_AGENT_INFO is deprecated in gpg2.1,
  # so we try to connect to a possibly running agent here
  gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
  
  A different patch that /just/ checks connectivity via gpg-agent.
  
  @@ -1562,14 +1562,8 @@ function gpg_pass_pipein {
  # 3 cannot connect to gpg-agent
  function gpg_agent_avail {
  local ERR=1
  - if var_isset GPG_AGENT_INFO; then
  - ps -p $(echo $GPG_AGENT_INFO|awk -F: '{print $2}') > /dev/null 2>&1 && \
  - ERR=0 || ERR=2
  - else
  - # GPG_AGENT_INFO is deprecated in gpg2.1,
  - # so we try to connect to a possibly running agent here
  - gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
  - fi
  + # Try to connect to a possibly running agent here
  + gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
  
  return $ERR
  }
  
  Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ftplicity/bugs/101/
  
  To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Bugs: ~~#101~~
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - ede - 2016-10-18
    
    how about first trying to connect and validate GPG_AGENT_INFO on error only? ..ede
    
    On 18.10.2016 17:05, ede wrote:
    
    wouldn't the preset GPG_AGENT_INFO with the pid 0 not warrant a stale error message as well?
    
    ..ede
    
    On 18.10.2016 16:46, Thomas Harning Jr. wrote:
    
    I have fully tested both patches with GnuPG 2.1.x (2.1.11 and 2.1.12) and have done a quick test on GnuPG 2.0.x (2.0.30) to see that gpg-agent behaves properly in the case of: * Agent running but no environment (GnuPG 2.0.x expected the environment variable present) - failed indicating no gpg-agent running in this session * Agent running with environment - found it * Agent not running with environment from old - IPC connect call failed ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ /[bugs:#101] <https://sourceforge.net/p/ftplicity/bugs/101/> https://sourceforge.net/p/ftplicity/bugs/101/ Duply does not check if GPG_AGENT_INFO is 'bogus'/ /Status:/ open /Group:/ duply /Labels:/ patch gpg /Created:/ Mon Oct 17, 2016 10:54 PM UTC by Thomas Harning Jr. /Last Updated:/ Mon Oct 17, 2016 10:54 PM UTC /Owner:/ ede If GPG_AGENT_INFO is setup by the default Xinit scripts as they are in Ubuntu, then the value will be invalid. See: https://wiki.debian.org/Teams/GnuPG/UsingGnuPGv2 for documentation about this. They set PID to 0 (since they don't know the running daemon's PID) and send things along. Upstream suggests calling out to the agent to check on the agent, but the suggested method there (https://lists.gnupg.org/pipermail/gnupg-devel/2015-March/029601.html) creates an agent (not sure if that's desired or not). A mechanism that seems to be a sure-fire fix that should be GPG 2.0 compatible is to simply connect to the agent via gpg-agent to verify connectivity, however we lose out on details about stale PID environment. Inlined patch to check if the PID is zero and skips the PID sanity check in that case. @@ -1563,9 +1563,15 @@ function gpg_pass_pipein { function gpg_agent_avail { local ERR=1 if var_isset GPG_AGENT_INFO; then - ps -p $(echo $GPG_AGENT_INFO|awk -F: '{print $2}') > /dev/null 2>&1 && \ - ERR=0 || ERR=2 - else + local GPG_AGENT_PID=$(echo $GPG_AGENT_INFO|awk -F: '{print $2}') + if [ "$GPG_AGENT_PID" != "0" ]; then + ps -p "$GPG_AGENT_PID" > /dev/null 2>&1 && \ + ERR=0 || ERR=2 + fi + fi + # If we know that the PID isn't stale, try to connect to an agent + # - we could skip to this, but we wouldn't be told about stale environment variables + if [ "$ERR" -ne "2" ]; then # GPG_AGENT_INFO is deprecated in gpg2.1, # so we try to connect to a possibly running agent here gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3 A different patch that /just/ checks connectivity via gpg-agent. @@ -1562,14 +1562,8 @@ function gpg_pass_pipein { # 3 cannot connect to gpg-agent function gpg_agent_avail { local ERR=1 - if var_isset GPG_AGENT_INFO; then - ps -p $(echo $GPG_AGENT_INFO|awk -F: '{print $2}') > /dev/null 2>&1 && \ - ERR=0 || ERR=2 - else - # GPG_AGENT_INFO is deprecated in gpg2.1, - # so we try to connect to a possibly running agent here - gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3 - fi + # Try to connect to a possibly running agent here + gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3 return $ERR } ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ftplicity/bugs/101/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
    
    [bugs:#101] https://sourceforge.net/p/ftplicity/bugs/101/ Duply does not check if GPG_AGENT_INFO is 'bogus'
    
    Status: open
    Group: duply
    Labels: patch gpg
    Created: Mon Oct 17, 2016 10:54 PM UTC by Thomas Harning Jr.
    Last Updated: Tue Oct 18, 2016 02:46 PM UTC
    Owner: ede
    
    If GPG_AGENT_INFO is setup by the default Xinit scripts as they are in Ubuntu, then the value will be invalid.
    See: https://wiki.debian.org/Teams/GnuPG/UsingGnuPGv2 for documentation about this.
    They set PID to 0 (since they don't know the running daemon's PID) and send things along.
    
    Upstream suggests calling out to the agent to check on the agent, but the suggested method there (https://lists.gnupg.org/pipermail/gnupg-devel/2015-March/029601.html) creates an agent (not sure if that's desired or not).
    
    A mechanism that seems to be a sure-fire fix that should be GPG 2.0 compatible is to simply connect to the agent via gpg-agent to verify connectivity, however we lose out on details about stale PID environment.
    
    Inlined patch to check if the PID is zero and skips the PID sanity check in that case.
    
    @@ -1563,9 +1563,15 @@ function gpg_pass_pipein {
    function gpg_agent_avail {
    local ERR=1
    if var_isset GPG_AGENT_INFO; then
    - ps -p $(echo $GPG_AGENT_INFO|awk -F: '{print $2}') > /dev/null 2>&1 && \
    - ERR=0 || ERR=2
    - else
    + local GPG_AGENT_PID=$(echo $GPG_AGENT_INFO|awk -F: '{print $2}')
    + if [ "$GPG_AGENT_PID" != "0" ]; then
    + ps -p "$GPG_AGENT_PID" > /dev/null 2>&1 && \
    + ERR=0 || ERR=2
    + fi
    + fi
    + # If we know that the PID isn't stale, try to connect to an agent
    + # - we could skip to this, but we wouldn't be told about stale environment variables
    + if [ "$ERR" -ne "2" ]; then
    # GPG_AGENT_INFO is deprecated in gpg2.1,
    # so we try to connect to a possibly running agent here
    gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
    
    A different patch that /just/ checks connectivity via gpg-agent.
    
    @@ -1562,14 +1562,8 @@ function gpg_pass_pipein {
    # 3 cannot connect to gpg-agent
    function gpg_agent_avail {
    local ERR=1
    - if var_isset GPG_AGENT_INFO; then
    - ps -p $(echo $GPG_AGENT_INFO|awk -F: '{print $2}') > /dev/null 2>&1 && \
    - ERR=0 || ERR=2
    - else
    - # GPG_AGENT_INFO is deprecated in gpg2.1,
    - # so we try to connect to a possibly running agent here
    - gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
    - fi
    + # Try to connect to a possibly running agent here
    + gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
    
    return $ERR
    }
    
    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ftplicity/bugs/101/
    
    To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
    
    Related
    
    Bugs: ~~#101~~
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Thomas Harning Jr. - 2016-10-18
      
      Verifying only on failure is a good idea. If it fails to connect, it helps to know what the error is.
      Regarding PID indicated as zero - I suppose indicating stale process could be considered correct too, perhaps the fix could be (pseudocode for now)
      
      Try to connect to gpg-agent and set error code:
      If non-zero error result
      
      Check to see if there is a GPG_AGENT_INFO and if so, analyze it to see if a different error code should be returned
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - ede - 2016-10-18
        
        sounds good! feel free to suggest a patch. if not i will come up w/ something tomorrow. thx agn.. ede
        
        On 18.10.2016 17:23, Thomas Harning Jr. wrote:
        
        Verifying only on failure is a good idea. If it fails to connect, it helps to know what the error is.
        Regarding PID indicated as zero - I suppose indicating stale process could be considered correct too, perhaps the fix could be (pseudocode for now)
        
        Try to connect to gpg-agent and set error code:
        If non-zero error result
        - Check to see if there is a GPG_AGENT_INFO and if so, analyze it to see if a different error code should be returned
        
        [bugs:#101] https://sourceforge.net/p/ftplicity/bugs/101/ Duply does not check if GPG_AGENT_INFO is 'bogus'
        
        Status: open
        Group: duply
        Labels: patch gpg
        Created: Mon Oct 17, 2016 10:54 PM UTC by Thomas Harning Jr.
        Last Updated: Tue Oct 18, 2016 02:46 PM UTC
        Owner: ede
        
        If GPG_AGENT_INFO is setup by the default Xinit scripts as they are in Ubuntu, then the value will be invalid.
        See: https://wiki.debian.org/Teams/GnuPG/UsingGnuPGv2 for documentation about this.
        They set PID to 0 (since they don't know the running daemon's PID) and send things along.
        
        Upstream suggests calling out to the agent to check on the agent, but the suggested method there (https://lists.gnupg.org/pipermail/gnupg-devel/2015-March/029601.html) creates an agent (not sure if that's desired or not).
        
        A mechanism that seems to be a sure-fire fix that should be GPG 2.0 compatible is to simply connect to the agent via gpg-agent to verify connectivity, however we lose out on details about stale PID environment.
        
        Inlined patch to check if the PID is zero and skips the PID sanity check in that case.
        
        @@ -1563,9 +1563,15 @@ function gpg_pass_pipein {
        function gpg_agent_avail {
        local ERR=1
        if var_isset GPG_AGENT_INFO; then
        - ps -p $(echo $GPG_AGENT_INFO|awk -F: '{print $2}') > /dev/null 2>&1 && \
        - ERR=0 || ERR=2
        - else
        + local GPG_AGENT_PID=$(echo $GPG_AGENT_INFO|awk -F: '{print $2}')
        + if [ "$GPG_AGENT_PID" != "0" ]; then
        + ps -p "$GPG_AGENT_PID" > /dev/null 2>&1 && \
        + ERR=0 || ERR=2
        + fi
        + fi
        + # If we know that the PID isn't stale, try to connect to an agent
        + # - we could skip to this, but we wouldn't be told about stale environment variables
        + if [ "$ERR" -ne "2" ]; then
        # GPG_AGENT_INFO is deprecated in gpg2.1,
        # so we try to connect to a possibly running agent here
        gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
        
        A different patch that /just/ checks connectivity via gpg-agent.
        
        @@ -1562,14 +1562,8 @@ function gpg_pass_pipein {
        # 3 cannot connect to gpg-agent
        function gpg_agent_avail {
        local ERR=1
        - if var_isset GPG_AGENT_INFO; then
        - ps -p $(echo $GPG_AGENT_INFO|awk -F: '{print $2}') > /dev/null 2>&1 && \
        - ERR=0 || ERR=2
        - else
        - # GPG_AGENT_INFO is deprecated in gpg2.1,
        - # so we try to connect to a possibly running agent here
        - gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
        - fi
        + # Try to connect to a possibly running agent here
        + gpg-agent > /dev/null 2>&1 && ERR=0 || ERR=3
        
        return $ERR
        }
        
        Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ftplicity/bugs/101/
        
        To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
        
        Related
        
        Bugs: ~~#101~~
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thomas Harning Jr. - 2016-10-18

Update patch attached - takes the gpg-agent fix and does an error diagnosis afterwards.

gpg-agent-fixup.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ede - 2016-10-21

hey Thomas,

added a modified version of what we talked about. please try the latest snapshot
http://duply.net/wiki/index.php/Duply-code#Latest_Development_Snapshot

..ede

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Thomas Harning Jr. - 2016-10-21
  
  Works good!
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ede - 2016-10-23

status: open --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ede - 2016-10-23

thx! will be in the next release.. ede

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Duply does not check if GPG_AGENT_INFO is 'bogus'

Group

Searches

Help

#101 Duply does not check if GPG_AGENT_INFO is 'bogus'

Related

Discussion

Related

Related

Related

Related

Related