nms-cgi-devel — Developers discussion for NMS CGI programs

Re: [Nms-cgi-devel] NMSBoard data format question...

[Nick C. <ni...@cl...>]

On Thu, Feb 06, 2003 at 03:59:02PM -0500, Wizard wrote:
> Just to respond to the concerns that Nick and Simon had regarding the
> "XML-like/unlike" format specified for NMSBoard; I created a DTD that
> defines the data format. It appears to validate with both my text editor and
> IE6 (in IE6 you can collapse/expand the entries...cool!). This should
> restrict an XML editor from munging the format.
> 
> The question is, should I include it in the distribution, or would that
> indicate that we are using XML, as I would also have to rename the data file
> with an .xml extension and add <?xml?> and <!DOCTYPE> tags? Another option
> would be to link to it through a common URL, like
> 'http://nms-cgi.sourceforge.net/nmsboard.dtd', which means that we would
> have sole control over the format.

If it's not really XML, it shouldn't have a dtd IMO.

If we want to avoid confusion with XML, how about just avoiding
anglebrackets, e.g. use "[foo]bah[/foo]" instead of the XML like
"<foo>bar</foo>". 

--
Nick

[Nms-cgi-devel] Re: NMSTreq and other modules...

[Nick C. <ni...@cl...>]

On Thu, Feb 06, 2003 at 11:59:49AM -0500, Wizard wrote:
> I was hoping to include NMSTreq.pm from Nick's TFMail for the email
> notification feature of NMSBoard.

There's nothing about emails in NMStreq - it's a CGI.pm wrapper, a
config file reader and a templating engine all munged into a single
module.

> Should I include it in my libs structure or is there some way in which we
> can create a symlink in the CVS tree?

For now, I think, copy and paste the bits you want.  Once everything
has settled down a bit we can look at factoring out a common superclass
if there's a lot of duplicated code.

> Where should it be?
>     CGI::NMS::NMSTreq?

I don't think NMSTreq should go in CGI::NMS, it's too much of a mixture
of things.  I would move the bits of it you want to 
CGI::NMS::Script::NMSBoard::SomeThing or suchlike.

>     CGI::NMS::Scripts::Common::NMSTreq?

To me, that says it's part of the Common.pl CGI script.

>     CGI::NMS::Scripts::NMSTreq?

... and that would be for the NMSTreq.pl CGI script.

> I may also include some other common stuff as well, but I have to look
> first. If I do find other code that I can steal, Should I create a
> package?  a module? just paste it?

I would just copy and paste for now, see what you end up with.

--
Nick

[Nms-cgi-devel] NMSBoard data format question...

[Wizard <wi...@ne...>]

Just to respond to the concerns that Nick and Simon had regarding the
"XML-like/unlike" format specified for NMSBoard; I created a DTD that
defines the data format. It appears to validate with both my text editor and
IE6 (in IE6 you can collapse/expand the entries...cool!). This should
restrict an XML editor from munging the format.

The question is, should I include it in the distribution, or would that
indicate that we are using XML, as I would also have to rename the data file
with an .xml extension and add <?xml?> and <!DOCTYPE> tags? Another option
would be to link to it through a common URL, like
'http://nms-cgi.sourceforge.net/nmsboard.dtd', which means that we would
have sole control over the format.
Let me know,
Grant M.

[Nms-cgi-devel] NMSTreq and other modules...

[Wizard <wi...@ne...>]

I was hoping to include NMSTreq.pm from Nick's TFMail for the email
notification feature of NMSBoard. These are my questions:

Should I include it in my libs structure or is there some way in which we
can create a symlink in the CVS tree?

Where should it be?
    CGI::NMS::NMSTreq?
    CGI::NMS::Scripts::Common::NMSTreq?
    CGI::NMS::Scripts::NMSTreq?


I may also include some other common stuff as well, but I have to look
first. If I do find other code that I can steal, Should I create a package?
a module? just paste it?

Let me know,
Grant M.

[Nms-cgi-devel] NMSBoard pre-alpha2

[Wizard <wi...@ne...>]

I just checked in try number 2 of NMSView.pl. I am hoping that this is
pretty close to what we'll end up with, not including a few other features
(caching for one, which I believe will be done in the nmsview.pl file prior
to creating the DataView objects).
  I still have to go back through the various discussion and add whatever it
was we discussed, so if you see something missing that we talked about,
don't freak out. If I plan on leaving it out, I'll post to the list.
Let me know if there are any issues with this version,
Grant M.

[Nms-cgi-devel] Re: [Nms-cgi-commits] CVS Commit

[Nick C. <ni...@cl...>]

On Sat, Feb 01, 2003 at 09:46:47AM -0800, Nick Cleaton wrote:
> 
> Added Files:
> 	index.shtml 
> Log Message:
> * add /v2/index.shtml to web site.  Very rough and ready.

/v2 in CVS now has pretty much everything needed to make releases
of FormMail based on the modules.  See /v2/README.developer.pod
and /v2/Makefile for details.

I have it set to upload to /v2 for now, which isn't linked from
the rest of the site.

The one thing I've done that I'm not really happy with is use
dates as version numbers, so the latest version is called
"version 2003-02-02-1726", rather than "version 3.14".

I suspect that this will cause problems, since users won't know
which of "2.21" and "2003-02-02-1726" is newer.

My thinking at the moment is that a file in CVS will record a
mapping between change dates and version numbers (starting from
3.01 maybe) and new version numbers will be allocated
automatically at release.

The pre-release procedure would be something like:

  check in your changes

  run the script that adds the dates of the changes you just
  made to the version number map.

  check the version number map into CVS

--
Nick

RE: [Nms-cgi-devel] you know who your friends are

[Wizard <wi...@ne...>]

> Now I know what to look for, it seems that www.flirble.org has had 1670
> attempts since June 2001.
>
> Nicholas Clark

I've had 81 attempts since January 1. That's better than the click-thru
rates of any single banner add except for The Boston Food Bank. The only 404
request that exceeds it is for variations on "winnt/system32/cmd.exe", which
beats it by 11.
Grant M.

[Nms-cgi-devel] you know who your friends are

[Nicholas C. <ni...@un...>]

For some reason I'm tailing the ccl4.org error log. I spotted this:

[Sat Feb  1 11:10:54 2003] [error] [client 172.130.218.101] script not found or unable to stat: /data/vhost/www.ccl4.org/cgi-bin/formmail.pl
[Sat Feb  1 11:10:57 2003] [error] [client 172.130.218.101] script not found or unable to stat: /data/vhost/www.ccl4.org/cgi-bin/FormMail.pl
[Sat Feb  1 11:11:07 2003] [error] [client 172.130.218.101] script not found or unable to stat: /data/vhost/www.ccl4.org/cgi-bin/formmail.cgi
[Sat Feb  1 11:11:17 2003] [error] [client 172.130.218.101] script not found or unable to stat: /data/vhost/www.ccl4.org/cgi-bin/FormMail.cgi

whois says that 172.130.218.101 happens to be an AOL netblock

Interesting, but not surprising. A brute force attempt to try to find a
FormMail script to exploit. There are no other ccl4.org hits from that host.

Now I know what to look for, it seems that www.flirble.org has had 1670
attempts since June 2001.

Nicholas Clark

RE: [Nms-cgi-devel] NMSView base code available...

[Wizard <wi...@ne...>]

> TFmail uses {=  =} as delimiters.
{= =} it is then.
Grant M.

Re: [Nms-cgi-devel] NMSView base code available...

[Nick C. <ni...@cl...>]

On Fri, Jan 31, 2003 at 11:30:26AM -0500, Wizard wrote:
> > I've never seen an html editor munge [% %], any that do could be
> > considered to be considerably broken IMO.
> 
> I don't regularly use them myself, so I'm not really the person to ask, but
> I HAVE seen my share of "considerably broken" software out there ;-), and I
> can see the potential. In the end it's up to you guys. The only time I'm
> really going to be insistent about anything is when it means substantially
> more work for me (Grant 'TLB' Mongardi, "That Lazy Bastard!" ;-). If you
> want me to use [% %], then I can use [% %].

I think Simon is right, probably best to use the same as TFmail
at least for now.  It'll be easy to change it later if we want to.

TFmail uses {=  =} as delimiters.

--
Nick

RE: [Nms-cgi-devel] BTW, you dint answer my question...

[Wizard <wi...@ne...>]

> I think so.  Be a bit careful though - CVS makes it very hard to delete
> or rename directories, so don't check in too much stuff that you'll
> later decide should be called something else.
Yeah, that's my biggest issue with all this: I've only used proprietary
version control systems (DesignSync & IPGear). The majority of the stuff
that I've done in Perl has been just as a 'lone hack', so don't say that you
haven't been warned ;-).
I'll be careful,
Grant M.

Re: [Nms-cgi-devel] BTW, you dint answer my question...

[Nick C. <ni...@cl...>]

On Fri, Jan 31, 2003 at 11:38:13AM -0500, Wizard wrote:
> Should I continue checking code, or not?

I think so.  Be a bit careful though - CVS makes it very hard to delete
or rename directories, so don't check in too much stuff that you'll
later decide should be called something else.

--
Nick

[Nms-cgi-devel] BTW, you dint answer my question...

[Wizard <wi...@ne...>]

Should I continue checking code, or not?
After this round, I think it couldn't hurt. Perhaps we could create a
separate branch for pre-alpha called /DONT_USE_THIS or something?
Let me know,
Grant M.

RE: [Nms-cgi-devel] NMSView base code available...

[Wizard <wi...@ne...>]

> I've never seen an html editor munge [% %], any that do could be
> considered to be considerably broken IMO.

I don't regularly use them myself, so I'm not really the person to ask, but
I HAVE seen my share of "considerably broken" software out there ;-), and I
can see the potential. In the end it's up to you guys. The only time I'm
really going to be insistent about anything is when it means substantially
more work for me (Grant 'TLB' Mongardi, "That Lazy Bastard!" ;-). If you
want me to use [% %], then I can use [% %].

Grant M.

Re: [Nms-cgi-devel] NMSView base code available...

[Nick C. <ni...@cl...>]

On Fri, Jan 31, 2003 at 11:20:45AM -0500, Wizard wrote:
> Sorry, typo: CGI::NMS::Script::NMSBoard::Data

Good.

> > No, that allows any file on the system to be treated as a config file.
> Good point about the anonymous FTP. What I think I'll do is add the path to
> the USER CONFIGURATION values in the scripts, that way if they want to
> change the path, they can.

Fine.

--
Nick

RE: [Nms-cgi-devel] NMSView base code available...

[Wizard <wi...@ne...>]

> I've seen __NMS_CFG_ITEM__ used for this stuff from time to time.
Works for me, /__NMS_CFG_ITEM_(\w)__/.

> CGI::NMS::Script::NMSBoard::Data ?  IMO  CGI::NMS::Script::Data::* would
> be for an NMS script called 'Data'.
Sorry, typo: CGI::NMS::Script::NMSBoard::Data

> No, that allows any file on the system to be treated as a config file.
Good point about the anonymous FTP. What I think I'll do is add the path to
the USER CONFIGURATION values in the scripts, that way if they want to
change the path, they can.

> That's very safe, but also quite limited for the users.
True, but it could be part of the admin package, but I'm not stuck on the
idea.

Thanks again,
Grant M.

RE: [Nms-cgi-devel] NMSView base code available...

[Simon W. <es...@ou...>]

On Fri, 2003-01-31 at 15:50, Wizard wrote:
> 
> > In that case, it might be better to have some sort of non-alpha
> > delimiter, e.g.
> >   '<a href="/new_path[% NMS_CFG_ITEM %]_wwwpost_url">Try the new list</a>'
> I thought of that, but the problem I see is what universal delimeter won't
> be munged by any of the HTML editors (I suspect that this is what most of
> our users will use)? Anything not A-Z, a-z, _, !, ? or - may very well get
> transformed. Also, anything like "<!-- -->" may be invisible on some
> editors, confusing the user. Any suggestions are welcome.

Would it make sense to use the same delimiters as are used in the TFMail
templates ? Consistency++ :)

I've never seen an html editor munge [% %], any that do could be
considered to be considerably broken IMO.

Simon.

Re: [Nms-cgi-devel] NMSView base code available...

[Nick C. <ni...@cl...>]

On Fri, Jan 31, 2003 at 10:50:01AM -0500, Wizard wrote:
> 
> > In that case, it might be better to have some sort of non-alpha
> > delimiter, e.g.
> >   '<a href="/new_path[% NMS_CFG_ITEM %]_wwwpost_url">Try the new list</a>'
> I thought of that, but the problem I see is what universal delimeter won't
> be munged by any of the HTML editors (I suspect that this is what most of
> our users will use)? Anything not A-Z, a-z, _, !, ? or - may very well get
> transformed. Also, anything like "<!-- -->" may be invisible on some
> editors, confusing the user. Any suggestions are welcome.

I've seen __NMS_CFG_ITEM__ used for this stuff from time to time.

> > The scripts are all scripts, but not every module in CGI::NMS:: is
> > associated with a particular script, e.g. CGI::NMS::Charset under /v2
> > in the CVS tree.
> Ok, that's valid. CGI::NMS::Script::Data* it is.

CGI::NMS::Script::NMSBoard::Data ?  IMO  CGI::NMS::Script::Data::* would
be for an NMS script called 'Data'.

> >   # check if 'cfg' is set via the URL query_string, if so use that.
> >   my $cfg_input = $cgi_data->param('cfg');
> >   if ( defined $cfg_input ) {
> >     $cfg_input =~ /^([\w\-]{1,100})$/ or die "bad cfg value [$cfg_input]";
> >     $def_cfg = "./conf/$1.cfg";
> >   }
> This isn't quite what I had planned but I understand what you are saying. I
> had hoped not to limit config files to any specific directory. What I was
> planning was to limit the path to specific characters ('.', '/', '\', ' ',
> '-' and \w). Is this not enough?

No, that allows any file on the system to be treated as a config file.
The attacker my be able to upload a file somewhere else (an incoming
FTP location maybe) or use this to trick the script into reading some
other arbitrary file as a config file and getting confused.

> There is also another option which I've used in past projects that specifies
> a separate list of config locations, i.e., "cfg_1 = ./nms.cfg", where the
> script is passed the index of the configuration file (&cfg=1). Is this a
> safer or better way to go?

That's very safe, but also quite limited for the users.

--
Nick

RE: [Nms-cgi-devel] NMSView base code available...

[Wizard <wi...@ne...>]

> Yes, I think that's better.  /e is fine - it just makes the code on the
> right hand side of the replace act as code, the same as code elsewhere
> in your script.  You'd be right to be nervous of user input anywhere
> neat /ee though, because that's really a string eval.
That's fine. Consider it done.

> In that case, it might be better to have some sort of non-alpha
> delimiter, e.g.
>   '<a href="/new_path[% NMS_CFG_ITEM %]_wwwpost_url">Try the new list</a>'
I thought of that, but the problem I see is what universal delimeter won't
be munged by any of the HTML editors (I suspect that this is what most of
our users will use)? Anything not A-Z, a-z, _, !, ? or - may very well get
transformed. Also, anything like "<!-- -->" may be invisible on some
editors, confusing the user. Any suggestions are welcome.

> The scripts are all scripts, but not every module in CGI::NMS:: is
> associated with a particular script, e.g. CGI::NMS::Charset under /v2
> in the CVS tree.
Ok, that's valid. CGI::NMS::Script::Data* it is.

> You read the config filename from a CGI input, and call open() on it
> with no checking, so a 'cfg' value of "|`rm -rf /`" would cause the
> command 'rm -rf /' to run.
Yes, that's what I pointed out.

>   # check if 'cfg' is set via the URL query_string, if so use that.
>   my $cfg_input = $cgi_data->param('cfg');
>   if ( defined $cfg_input ) {
>     $cfg_input =~ /^([\w\-]{1,100})$/ or die "bad cfg value [$cfg_input]";
>     $def_cfg = "./conf/$1.cfg";
>   }
This isn't quite what I had planned but I understand what you are saying. I
had hoped not to limit config files to any specific directory. What I was
planning was to limit the path to specific characters ('.', '/', '\', ' ',
'-' and \w). Is this not enough?
There is also another option which I've used in past projects that specifies
a separate list of config locations, i.e., "cfg_1 = ./nms.cfg", where the
script is passed the index of the configuration file (&cfg=1). Is this a
safer or better way to go?

> Also, in the open in CGI::NMS::Config you should add a '<' to the front
> of the filename so that the open can't act as a piped open and run
> commands even if an attacker gets something past the checks.
Yup, I'll do that.

Re: [Nms-cgi-devel] NMSView base code available...

[Nick C. <ni...@cl...>]

On Fri, Jan 31, 2003 at 08:23:52AM -0500, Wizard wrote:
> > A few points:
> > You can use get() like this:
> >
> >   $_ =~ s/PARSE_ITEM_([a-zA-Z0-9_-]+)/ $cfg->get("MESSAGE_$1") /ge;
> Yeah, I thought of that, but /e always makes me nervous parsing external
> data, so I've tried to avoid it. If you think it would be better to do it
> that way, then I'd be happy to change it.

Yes, I think that's better.  /e is fine - it just makes the code on the
right hand side of the replace act as code, the same as code elsewhere
in your script.  You'd be right to be nervous of user input anywhere
neat /ee though, because that's really a string eval.

> 
> > Also, the patten should probably start with:
> >   /\bPARSE_ITEM_
> The tag name is a poor choice, and I plan on standardizing on NMS_* for all
> tags, but the reason that I didn't do word boundaries was because I'm not
> sure that there won't be a situation in which tags will need to be appended
> to strings. For lack of a better example:
> '<a href="/new_pathNMS_CFG_ITEM_wwwpost_url">Try the new list</a>'

In that case, it might be better to have some sort of non-alpha
delimiter, e.g.

  '<a href="/new_path[% NMS_CFG_ITEM %]_wwwpost_url">Try the new list</a>'

since that'll make what's going on more obvious to someone reading
the template.

> > CGI::NMS::Data is badly named.  This module contains code that looks
> > pretty specific to nmsboard, so it shouldn't have such a general
> > sounding name.  How about something like
> > CGI::NMS::Script::NMSBoard::Data ?
> I'm not sure what the 'Script' is for (they're all scripts, right ;-).  How
> about CGI::NMS::NMSBoard::Data? There will also be a DataAdmin module, so
> I'll likely rename it DataView, also.

The scripts are all scripts, but not every module in CGI::NMS:: is
associated with a particular script, e.g. CGI::NMS::Charset under /v2
in the CVS tree.

I like the distinction of putting stuff specific to script foo under
CGI::NMS::Script::Foo.

> > You have at least one arbitrary command execution vulnerability in
> > there.
> I haven't done any escaping of CGI data yet (like .cfg filenames) but have
> every intention of doing so, if that is what you mean. If I'm missing
> something else, please let me know.
> (Clue please, so I don't have to go hunting. ;-)

You read the config filename from a CGI input, and call open() on it
with no checking, so a 'cfg' value of "|`rm -rf /`" would cause the
command 'rm -rf /' to run.

IMO instead of:

> # check if 'cfg' is set via the URL query_string, if so use that.
> $def_cfg = $cgi_data->param('cfg') if( $cgi_data->param('cfg') );

... you should be doing something more like:

  # check if 'cfg' is set via the URL query_string, if so use that.
  my $cfg_input = $cgi_data->param('cfg');
  if ( defined $cfg_input ) {
    $cfg_input =~ /^([\w\-]{1,100})$/ or die "bad cfg value [$cfg_input]";
    $def_cfg = "./conf/$1.cfg";
  }

... which tightly limits the name of the config file.

Also, in the open in CGI::NMS::Config you should add a '<' to the front
of the filename so that the open can't act as a piped open and run
commands even if an attacker gets something past the checks.

--
Nick

RE: [Nms-cgi-devel] NMSView base code available...

[Wizard <wi...@ne...>]

> A few points:
> You can use get() like this:
>
>   $_ =~ s/PARSE_ITEM_([a-zA-Z0-9_-]+)/ $cfg->get("MESSAGE_$1") /ge;
Yeah, I thought of that, but /e always makes me nervous parsing external
data, so I've tried to avoid it. If you think it would be better to do it
that way, then I'd be happy to change it.

> Also, the patten should probably start with:
>   /\bPARSE_ITEM_
The tag name is a poor choice, and I plan on standardizing on NMS_* for all
tags, but the reason that I didn't do word boundaries was because I'm not
sure that there won't be a situation in which tags will need to be appended
to strings. For lack of a better example:
'<a href="/new_pathNMS_CFG_ITEM_wwwpost_url">Try the new list</a>'
where 'wwwpost_url' is something like "/wwwpost.pl". In your example this
would not match. I'm not sure that this is something that is necessary
though, and if it's not a likely scenario, I don't have an issue with it.

> There's no need for all that \", better to use one of the alternatives
> to "...", such as qq{...}
>
> my $hiddens = qq{<input type="hidden" name="cfg" value="} .
>               $cfg->get("_cfgfile") . qq{" />\n};
An old printf() habit ;-).

> CGI::NMS::Data is badly named.  This module contains code that looks
> pretty specific to nmsboard, so it shouldn't have such a general
> sounding name.  How about something like
> CGI::NMS::Script::NMSBoard::Data ?
I'm not sure what the 'Script' is for (they're all scripts, right ;-).  How
about CGI::NMS::NMSBoard::Data? There will also be a DataAdmin module, so
I'll likely rename it DataView, also.

> You have at least one arbitrary command execution vulnerability in
> there.
I haven't done any escaping of CGI data yet (like .cfg filenames) but have
every intention of doing so, if that is what you mean. If I'm missing
something else, please let me know.
(Clue please, so I don't have to go hunting. ;-)
There is also a lot of other crap that I have to clean up and error check,
as well.

> Our CVS tree is world readable, and people may grab it before we think
> it's ready.  Also, there's a risk that you'll choose design strategy X
> and only find out that X is impossible to implement securely way down
> the line when you want to do a release.  Better to consider security
> right now.
I haven't 'not' considered it, but if you think that this is problem then I
can refrain from checking it in until it's mostly finished (I'd hate to do
that, though). I was doing this for just the reason that you specify: to get
feedback to make sure I wasn't headed somewhere that I shouldn't be. This is
really just an 'outline' of my thought-process for the overall functionality
of NMSBoard, and I was only hoping to get constructive criticism, like
you've done.

Thanks for the feedback. I'll take care of the issues that you've mentioned
and let me know if I should check anymore in.
Grant M.

Re: [Nms-cgi-devel] NMSView base code available...

[Nick C. <ni...@cl...>]

On Thu, Jan 30, 2003 at 08:42:41PM -0500, Wizard wrote:
> I posted the NMSView base code. It's just a working platform to work from,
> so please be kind. It'll start to take shape soon enough.
> Feel free to play with it. Let me know if you see any major problems.

A few points:

1)

in lib/CGI/NMS/Data:

  $_ =~ s/PARSE_ITEM_([a-zA-Z0-9_-]+)/$cfg->{ "MESSAGE_$1" }/g;
  # Had to use direct access because get() won't interpolate

You can use get() like this:

  $_ =~ s/PARSE_ITEM_([a-zA-Z0-9_-]+)/ $cfg->get("MESSAGE_$1") /ge;

because the /e causes the right hand side to be treated as code.

Also, the patten should probably start with:

  /\bPARSE_ITEM_

so that it doesn't match things like:

  SPARSE_ITEM_STASH

2)

my $hiddens = "<input type=\"hidden\" name=\"cfg\" value=\""
   .  $cfg->get( "_cfgfile" ) . "\" />\n";

There's no need for all that \", better to use one of the alternatives
to "...", such as qq{...}

my $hiddens = qq{<input type="hidden" name="cfg" value="} .
              $cfg->get("_cfgfile") . qq{" />\n};

3)

CGI::NMS::Data is badly named.  This module contains code that looks
pretty specific to nmsboard, so it shouldn't have such a general
sounding name.  How about something like
CGI::NMS::Script::NMSBoard::Data ?

4)

You have at least one arbitrary command execution vulnerability in
there.  I know it's tempting to ignore that while the thing is nowhere
near finished and then fix all the security holes before the first
release, but I would argue that it's better to fix them right now.

Our CVS tree is world readable, and people may grab it before we think
it's ready.  Also, there's a risk that you'll choose design strategy X
and only find out that X is impossible to implement securely way down
the line when you want to do a release.  Better to consider security
right now.

--
Nick

[Nms-cgi-devel] NMSView base code available...

[Wizard <wi...@ne...>]

I posted the NMSView base code. It's just a working platform to work from,
so please be kind. It'll start to take shape soon enough.
Feel free to play with it. Let me know if you see any major problems.
Thanks,
Grant M.
P.S.> I put links at the top for Thread Views and an alternative
configuration.
There is no posting yet.

RE: [Nms-cgi-devel] Need CVS login for NMSBOARD...

[Wizard <wi...@ne...>]

> There's something you have to do before being able to access the CVS
> server... you have to ssh into a server for something rather. It's in
> the docs.
export CVS_RSH=ssh - I did that.

> But you should still be able to connect... I think you're using the
> wrong server. I use cvs.nms-cgi.sourceforge.net
That's it! Duh!

> Also, it's easier if you export CVSROOT:
> export CVSROOT=neo...@cv...:/cvsroot/nms-cgi

I'll try that. Thanks,

Grant M.

Re: [Nms-cgi-devel] Need CVS login for NMSBOARD...

[Olivier D. <dr...@sh...>]

On Thu, Jan 30, 2003 at 04:20:34PM -0500, Wizard wrote:
>   I'm trying to import my base code for NMSBoard, but I'm having some
> problems (its been awhile ;-).
> I tried this:
> cvs -z3 -d:ext:neo...@so...:/cvsroot/nms-cgi import -m "NMSBoard
> Base code" nmsboard nms alpha
> 
> but received (after some amount of waiting):
> Secure connection to sourceforge.net refused
> cvs [import aborted]: end of file from server (consult above messages if
> any)
> 
> I'm using cygwin, but that shouldn't make any difference, should it?
> Any suggestions?

There's something you have to do before being able to access the CVS
server... you have to ssh into a server for something rather. It's in
the docs.

But you should still be able to connect... I think you're using the
wrong server. I use cvs.nms-cgi.sourceforge.net

Also, it's easier if you export CVSROOT:
export CVSROOT=neo...@cv...:/cvsroot/nms-cgi

then all you need to do is:
$ cvs import -m "NMSBoard Base code" nmsboard nms alpha
$ cvs co nmsboard
$ cvs ...
etc.

Each time you'll be prompted for your password.

For all your CVS needs use the CVS Book which you can download some
chapters for free here: http://cvsbook.red-bean.com/

Best CVS reference I've ever found!

Cheers,
-Olivier

-- 
                  __-/|    ? ?     |\-__
             __--/  /  \   (^^)   /  \  \--__
          _-/   /   /   \ / ( )  /   \   \   \-_
         /  /   /  /     ~(  ^^ ~     \  \   \  \
         / Oli Dragon    dr...@sh... \
        /  Sfwr Eng III  (  McMaster University  \
        /  /  /     __--_ (   ) __--__     \  \  \
        |  /  /  _/        \_ \_       \_  \  \  |
         \/  / _/            \_ \_       \_ \  \/
          \_/ /                -\_\        \ \_/
            \/                   -)         \/
                                *~
 ___--<******************************************************>--___
[http://pgp.mit.edu:11371/pks/lookup?search=olivier+dragon&op=index]
 ~~~--<******************************************************>--~~~