Skip Menu |

This queue is for tickets about the PlRPC CPAN distribution.

Report information
The Basics
Id: 7720
Status: resolved
Worked: 5 min
Priority: 0/
Queue: PlRPC
People
Owner: Nobody in particular
Requestors: rrv [...] uiuc.edu
Cc:
AdminCc:
Bug Information
Severity: Important
Broken in: 0.2018
Fixed in: (no value)

History Show all quoted text
  Mon Sep 20 22:55:19 2004 Guest - Ticket created
Subject: cipher broken by 0.2018
Show quoted text
> The RPC::PlServer::Comm module is now being used as > an encapsulated object $self->{'comm'}.
Good move. But client and server now need to pass their {'cipher'} values on to $self->{'comm'}. If I'm reading correctly, PlClient doesn't really support the user based cipher, a feature I was hoping to use. I've hacked PlServer.pm and t/lib.pl to get t/crypt.t to pass, but my hacks don't constitute a patch. Perhaps another day.
  Mon Sep 20 23:04:23 2004 Guest - Correspondence added
From: rrv [...] uiuc.edu
FWIW, my hack was identical to that suggested by rwjanes#primus.ca in response to Bug #7575. I hadn't noticed that little detail.
  Wed Sep 22 06:46:07 2004 Guest - Correspondence added
From: rwjanes [...] primus.ca
[guest - Mon Sep 20 22:55:19 2004]: Show quoted text
> If I'm reading correctly, PlClient doesn't really support the user > based cipher, a feature I was hoping to use.
The second test of crypt.t brings into play a user based cipher. You connect to the server from a location with multiple users named in the config file. Specify a user with a cipher (also specified in the config file). Once the welcome is sent, you better know the user cipher. PlRPC, without my patch, does not support user ciphers, in that the cipher on the server side doesn't change after the welcome. As I understand it, on the server side the accept is done in the child. Therefore, we don't need to save the original cipher.
  Wed Sep 22 06:56:05 2004 Guest - Correspondence added
From: rwjanes [...] primus.ca
[guest - Wed Sep 22 06:46:07 2004]: forgot to mention - use the usercipher => $usercipher to tell PlClient about the user cipher. PlClient will use the server cipher up to the welcome, then switch to the $usercipher.
  Wed Sep 22 08:51:04 2004 Guest - Correspondence added
From: rwjanes [...] primus.ca
[guest - Mon Sep 20 22:55:19 2004]: Show quoted text
> If I'm reading correctly, PlClient doesn't really support the user > based cipher, a feature I was hoping to use.
The second test of crypt.t brings into play a user based cipher. You connect to the server from a location with multiple users named in the config file. Specify a user with a cipher (also specified in the config file). Once the welcome is sent, you better know the user cipher. PlRPC, without my patch, does not support user ciphers, in that the cipher on the server side doesn't change after the welcome. As I understand it, on the server side the accept is done in the child. Therefore, we don't need to save the original cipher.
  Wed Sep 22 08:56:24 2004 Guest - Correspondence added
From: rwjanes [...] primus.ca
[guest - Wed Sep 22 06:56:05 2004]: Show quoted text
> [guest - Wed Sep 22 06:46:07 2004]: > > forgot to mention - use the usercipher => $usercipher to tell PlClient > about the user cipher. PlClient will use the server cipher up to > the welcome, then switch to the $usercipher. >
Oops, you're right. the usercipher code is in t/lib.pl, not PlClient.
  Thu May 24 17:16:53 2007 m.nooning [...] comcast.net - Correspondence added
From: m.nooning [...] comcast.net
Try PlRPC-0.2019
  Thu May 24 17:16:53 2007 The RT System itself - Status changed from 'new' to 'open'
  Sun Jun 17 16:21:57 2007 MNOONING [...] cpan.org - Correspondence added 5 min
This is a very old bug report CPAN Testers report no bugs in version 0.2019. Version 0.2020 is the same as 0.2019 except for getting rid of some .svn directories that got caught in the 0.2019 tar.gz file.
  Sun Jun 17 16:21:58 2007 MNOONING [...] cpan.org - Status changed from 'open' to 'resolved'