exec tickit.js NONE 1.1
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv9510

Added Files:
tickit.js
Log Message:
Initial TIC handler in JavaScript.
Currently just parses the TIC files, doesn't actually do anything.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.1 1.2
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv10032

Modified Files:
tickit.js
Log Message:
Verify the password in the TIC matches the PKTPWD in sbbsecho.cfg.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.2 1.3
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv14204

Modified Files:
tickit.js
Log Message:
Now works for me.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.3 1.4
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv17737

Modified Files:
tickit.js
Log Message:
Use -zd options for addfiles.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Hello deuce,

On 14 Dec 15 00:20, deuce wrote to CVS commit:

exec tickit.js 1.1 1.2
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv10032

Modified Files:
tickit.js
Log Message:
Verify the password in the TIC matches the PKTPWD in sbbsecho.cfg.

Shouldn't this be a new option field? If you don't have a PKTPWD set for echomail/netmail, you would still have to enable this, therefore enabling message packet passwords, in order to use TICs properly?

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

exec tickit.js 1.4 1.5
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv31321

Modified Files:
tickit.js
Log Message:
Make the area translation less ugly in the announce message.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Re: exec/tickit.js
By: Accession to deuce on Mon Dec 14 2015 06:10 am

Verify the password in the TIC matches the PKTPWD in sbbsecho.cfg.

Shouldn't this be a new option field? If you don't have a PKTPWD set for echomail/netmail, you would still have to enable this, therefore enabling message packet passwords, in order to use TICs properly?

I honestly have no idea. I found zero information about all the different passwords that a FidoNet configuration has and how they interact. All I know is that the TIC files I got from my hub have their Pw set as my PKTPWD. The (brand new -- thanks Michiel van der Vlist) FSP-1039 document does not reccomend accepting files without a password.

Where does the hub get the password it puts into the TIC files if not from the packet password?

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

exec tickit.js 1.5 1.6
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv32080

Modified Files:
tickit.js
Log Message:
Fix wildcard search for nodes... was skipping replacing the last element
with ALL.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Hello Deuce,

On 14 Dec 15 15:00, Deuce wrote to Accession:

Shouldn't this be a new option field? If you don't have a PKTPWD
set for echomail/netmail, you would still have to enable this,
therefore enabling message packet passwords, in order to use TICs
properly?

I honestly have no idea. I found zero information about all the
different passwords that a FidoNet configuration has and how they interact. All I know is that the TIC files I got from my hub have
their Pw set as my PKTPWD. The (brand new -- thanks Michiel van der Vlist) FSP-1039 document does not reccomend accepting files without a password.

Where does the hub get the password it puts into the TIC files if not
from the packet password?

In just about every software I've used so far, it is it's own entity, ie: "TICPWD" or "TIC password". As far as I've seen, message areas and file areas are completely separate from each other, and don't use the same passwords.

If your uplink never asked you for a TIC password, then maybe he just made it the same as your packet password.

For example, If I was to use all of the husky tools (ie: no Synchronet), I would use both HPT (for echomail and netmail) and HTICK (for files). There is separate config file options for pktpwd and ticpwd, which is why I was confused
and asked you about it.

It's possible they're one in the same in some of the older stuff.. IIRC, Allfix
is also separate from anything echomail/netmail related, but I never used it so
don't know specifics.

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/701)
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Re: exec/tickit.js
By: Nicholas Boel to Deuce on Mon Dec 14 2015 09:44 pm

In just about every software I've used so far, it is it's own entity, ie: "TICPWD" or "TIC password". As far as I've seen, message areas and file areas are completely separate from each other, and don't use the same passwords.

Sure, it's technically possible to use different passwords for TIC than for binkp, areafix, packets, etc. A straw poll of sysops hasn't shown any of them having a different packet password than the TIC password.

If someone actually has a config like that and can explain why, I'll consider it, but it would need the same wildcard ability as the PKTPWD lines in sbbsecho.cfg. All of these passwords (with the exception of the binkp one) basically do the same thing in the same way over the same link.

If your uplink never asked you for a TIC password, then maybe he just made it the same as your packet password.

I never selected a TICK password because I never wanted the files. Only reason I know what my TICK password is is because it's transferred in plain text in the TIC file.

For example, If I was to use all of the husky tools (ie: no Synchronet), I would use both HPT (for echomail and netmail) and HTICK (for files). There is separate config file options for pktpwd and ticpwd, which is why I was confused and asked you about it.

Sure, it's technically possible, but tickit.js is not intended to be a complete TICK solution. I'm not inclined to perpetuate needless complexity, so until there's a problem that needs solving, I'm not going to make the script more complex "Just In Case".

It's possible they're one in the same in some of the older stuff.. IIRC, Allfix is also separate from anything echomail/netmail related, but I never used it so don't know specifics.

That's the biggest problem I'm seeing with TICK stuff is that the majority of it is simply not documented. Some information can be gleaned from the various programs that do it, but not enough.

I see no reason not to require that the packet password and TICK password for a link to be the same. If there is a reason, and someone explains it, I'll consider changing that requirement.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

exec tickit.js 1.6 1.7
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv30741

Modified Files:
tickit.js
Log Message:
Remove the announce message generation. Synchronet has had a new file scan function for a very very long time now, we don't need to duplicate this functionality.

(Unless I misunderstand what the announce message is for?)



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Hello Deuce,

On 14 Dec 15 22:19, Deuce wrote to Nicholas Boel:

In just about every software I've used so far, it is it's own
entity, ie: "TICPWD" or "TIC password". As far as I've seen,
message areas and file areas are completely separate from each
other, and don't use the same passwords.

Sure, it's technically possible to use different passwords for TIC
than for binkp, areafix, packets, etc. A straw poll of sysops hasn't shown any of them having a different packet password than the TIC password.

In my case here, along with every link but one that I connect with, there are no packet passwords whatsoever. My only concern with using the same sbbsecho.cfg option for both, is that if I were to set people up with a file feed, and they specify a password for that, then I would be forced to configure
a message packet password as well.

If someone actually has a config like that and can explain why, I'll consider it, but it would need the same wildcard ability as the PKTPWD lines in sbbsecho.cfg. All of these passwords (with the exception of
the binkp one) basically do the same thing in the same way over the
same link.

I see what you're saying. I originally asked from my own perspective. I have over 70 links here, and if I were to start using this I would have to contact each and every one of them that gets a file feed from me, to make sure they now
have to setup a packet password in order for their future TIC files to work while still receiving message packets.

If you don't see an issue with something like that, then by all means continue and disregard what I've said.

If your uplink never asked you for a TIC password, then maybe he
just made it the same as your packet password.

I never selected a TICK password because I never wanted the files.
Only reason I know what my TICK password is is because it's
transferred in plain text in the TIC file.

For example, If I was to use all of the husky tools (ie: no
Synchronet), I would use both HPT (for echomail and netmail) and
HTICK (for files). There is separate config file options for
pktpwd and ticpwd, which is why I was confused and asked you about
it.

Sure, it's technically possible, but tickit.js is not intended to be a complete TICK solution. I'm not inclined to perpetuate needless complexity, so until there's a problem that needs solving, I'm not
going to make the script more complex "Just In Case".

Okay, no worries then. I just gave you a problem that would eventually need solving (or ignoring.. take your pick). You may not see this point of view since you are not a hub/host.. but if it's only meant to be something like Tinytic where it only works for an end point node and not a hub, then nevermind.

It's possible they're one in the same in some of the older stuff..
IIRC, Allfix is also separate from anything echomail/netmail
related, but I never used it so don't know specifics.

That's the biggest problem I'm seeing with TICK stuff is that the
majority of it is simply not documented. Some information can be
gleaned from the various programs that do it, but not enough.

I see no reason not to require that the packet password and TICK
password for a link to be the same. If there is a reason, and someone explains it, I'll consider changing that requirement.

I don't see a reason for them not to be the same either, but in doing so the way you have so far, you're forcing the use of packet passwords (while many choose not to use them at all) if you want to use tickit.js for a file ticker.

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Hello deuce,

On 15 Dec 15 15:29, deuce wrote to CVS commit:

exec tickit.js 1.6 1.7
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv30741

Modified Files:
tickit.js
Log Message:
Remove the announce message generation. Synchronet has had a new file scan function for a very very long time now, we don't need to
duplicate this functionality.

(Unless I misunderstand what the announce message is for?)

The announce message is basically so that it will either create a text file to be imported into a message base using smbutil, or something that can be imported directly to a message base, announcing any new files received that day.

There are stat reporting echoes on Fidonet as well as a bunch of othernets specifically for this. And in some cases (ie: Golded+) you can have a personal mail area setup (non-netmail or echomail) where you can import those announcement messages to, in case you didn't have a BBS to list/display and/or newscan files).

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Re: Re: exec/tickit.js
By: Accession to Deuce on Tue Dec 15 2015 05:25 pm

In my case here, along with every link but one that I connect with, there are no packet passwords whatsoever. My only concern with using the same sbbsecho.cfg option for both, is that if I were to set people up with a file feed, and they specify a password for that, then I would be forced to configure a message packet password as well.

I'm not sure what you mean... why would you set them up with a TICK password? If you (as the hub) don't configure a TICK password, there will be no Pw lines in the TIC file. If there's no PKTPWD lines in their sbbsecho.cfg, and you don't include a password in the TIC file, it should Just Work.

I see what you're saying. I originally asked from my own perspective. I have over 70 links here, and if I were to start using this I would have to contact each and every one of them that gets a file feed from me, to make sure they now
have to setup a packet password in order for their future TIC files to work while still receiving message packets.

So if you're the file source, you control if a password is included in the TIC file, not them. It is only in the case where you send them a TIC file with a password in it that they would need to use a packet password. Since the two passwords provide the same utility, it doesn't really make sense to use one and not the other.

If you don't see an issue with something like that, then by all means continue and disregard what I've said.

I'm not discregarding what you're saying. If I were, I would not be replying. Please don't assume that something other than complete agreement with everything you say is disregarding what you say.

I'm trying to have a discussion here, and you're complaining that I don't listen.

Okay, no worries then. I just gave you a problem that would eventually need solving (or ignoring.. take your pick). You may not see this point of view since you are not a hub/host.. but if it's only meant to be something like Tinytic where it only works for an end point node and not a hub, then nevermind.

I do not have a problem. You theorized that a problem might exist and now that I'm talking about how it would happen, you're complaining that I ignore you and can't see your point of view because I'm not a hub/host.


---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: exec/tickit.js
By: Accession to deuce on Tue Dec 15 2015 08:58 pm

The announce message is basically so that it will either create a text file to be imported into a message base using smbutil, or something that can be imported directly to a message base, announcing any new files received that day.

Right, and since Tickit.js only supports Synchronet, and Synchronet has new file scan support, this use case doesn't make much sense.

There are stat reporting echoes on Fidonet as well as a bunch of othernets specifically for this

The existance of these is what prompted removing the announce message. A Tickit announce ended up in FidoREQ, and I doubt the files are available for FREQ.

As for stat reporting stuff, it makes more sense to report *all* files rather than just ones that came in via an FDS. This would be a very different script... and again, does not belong in ticit.js.


---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Hello Deuce,

On 16 Dec 15 03:52, Deuce wrote to Accession:

In my case here, along with every link but one that I connect with,
there are no packet passwords whatsoever. My only concern with
using the same sbbsecho.cfg option for both, is that if I were to
set people up with a file feed, and they specify a password for
that, then I would be forced to configure a message packet password
as well.

I'm not sure what you mean... why would you set them up with a TICK password? If you (as the hub) don't configure a TICK password, there
will be no Pw lines in the TIC file. If there's no PKTPWD lines in
their sbbsecho.cfg, and you don't include a password in the TIC file,
it should Just Work.

I set them all up with a TIC password because the option was there and separate
from sbbsecho's PKTPWD line (using Husky's HTICK with Synchronet). If I were to
want to move over to utilize something you've made work well with Synchronet, it's going to be a pain in the ass adding everyone's TIC password as a PKTPWD line, and then telling them that their echomail/netmail won't be processed at their system due to me having to add a PKTPWD in replacement of their TIC password.

I see what you're saying. I originally asked from my own
perspective. I have over 70 links here, and if I were to start
using this I would have to contact each and every one of them that
gets a file feed from me, to make sure they now have to setup a
packet password in order for their future TIC files to work while
still receiving message packets.

So if you're the file source, you control if a password is included in
the TIC file, not them. It is only in the case where you send them a
TIC file with a password in it that they would need to use a packet password. Since the two passwords provide the same utility, it
doesn't really make sense to use one and not the other.

What's already done is done. I've been using TIC passwords for years now for *some* inkling of security. I felt that with the use of a CRAM-MD5 encrypted binkp connection, there was no need for packet password.

If you don't see an issue with something like that, then by all
means continue and disregard what I've said.

I'm not discregarding what you're saying. If I were, I would not be replying. Please don't assume that something other than complete
agreement with everything you say is disregarding what you say.

...?

I never assumed anything. I only said that if you don't see my situation proposed as an issue of any sort, disregard it. Not that you were already disregarding anything.

I'm trying to have a discussion here, and you're complaining that I
don't listen.

So am I, and no I'm not. Maybe you're not comprehending what I'm typing? I never said you don't listen. I basically said that you don't need to listen to me if you don't agree with me that it is an issue intermixing two completely different things (ie: message packets and TICs + files).

Okay, no worries then. I just gave you a problem that would
eventually need solving (or ignoring.. take your pick). You may not
see this point of view since you are not a hub/host.. but if it's
only meant to be something like Tinytic where it only works for an
end point node and not a hub, then nevermind.

I do not have a problem. You theorized that a problem might exist and
now that I'm talking about how it would happen, you're complaining
that I ignore you and can't see your point of view because I'm not a hub/host.

Again, you must not have read what I wrote correctly.

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Hello Deuce,

On 16 Dec 15 03:56, Deuce wrote to Accession:

The announce message is basically so that it will either create a
text file to be imported into a message base using smbutil, or
something that can be imported directly to a message base,
announcing any new files received that day.

Right, and since Tickit.js only supports Synchronet, and Synchronet
has new file scan support, this use case doesn't make much sense.

It basically lets others know what new files your system received that day, without having to connect to your BBS on a daily basis. All other tickers out there do it, so please don't shoot the messenger.

There are stat reporting echoes on Fidonet as well as a bunch of
othernets specifically for this

The existance of these is what prompted removing the announce message.
A Tickit announce ended up in FidoREQ, and I doubt the files are
available for FREQ.

If the system (like mine, and a bunch of others I know of) manually move files around using scripts, as well as some kind of FREQ handler, then I don't doubt at all that the files are available via FREQ. YMMV.

As for stat reporting stuff, it makes more sense to report *all* files rather than just ones that came in via an FDS. This would be a very different script... and again, does not belong in ticit.js.

Reporting ALL files on a daily basis? I don't think that's what the announce message was intended for whatsoever.

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Re: Re: exec/tickit.js
By: Accession to deuce on Mon Dec 14 2015 06:10 am

Verify the password in the TIC matches the PKTPWD in sbbsecho.cfg.

Shouldn't this be a new option field? If you don't have a PKTPWD set for echomail/netmail, you would still have to enable this, therefore enabling message packet passwords, in order to use TICs properly?

I honestly have no idea. I found zero information about all the different passwords that a FidoNet configuration has and how they interact. All I know is that the TIC files I got from my hub have their Pw set as my PKTPWD. The (brand new -- thanks Michiel van der Vlist) FSP-1039 document does not reccomend accepting files without a password.

Where does the hub get the password it puts into the TIC files if not from the packet password?

I have the areafix (messages) be sbbsecho one pw, while allfix dose fdn's and has a differnet pw.

also I thought to add, a way to post the new files got in some echos (more like a bunch of them)


---

Rob Starr
Lord Time SysOp of
Time Warp of the Future BBS
Telnet://Time.Darktech.Org:24 or
Telnet://Time.Synchro.Net:24 (qwk or ftn & e-mail)
ICQ # 11868133 or # 70398519 Jabber : lordtime2000@gmail.com
Yahoo : lordtime2000 AIM : LordTime20000 MSN : Lord Time
Astra : lord_time X-Box : Lord Time 2000 oovoo : lordtime2000
---
þ Synchronet þ Time Warp of the Future BBS - Home of League 10 IBBS Games

Re: Re: exec/tickit.js
By: Accession to Deuce on Wed Dec 16 2015 02:56 pm

So if you're the file source, you control if a password is included in the TIC file, not them. It is only in the case where you send them a TIC file with a password in it that they would need to use a packet password. Since the two passwords provide the same utility, it
doesn't really make sense to use one and not the other.

What's already done is done. I've been using TIC passwords for years now for *some* inkling of security. I felt that with the use of a CRAM-MD5 encrypted binkp connection, there was no need for packet password.

Why do/did you feel that fire transfers need some extra "security", but packets don't?

Honestly, what I would end up suggesting if all your links are binkp is to simply drop the TICK password just like you did the packet password rather
than add a packet password. It really doesn't add any extra security at all unless the system is misconfigured.

Again, you must not have read what I wrote correctly.

Or it was worded poorly.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: exec/tickit.js
By: Accession to Deuce on Wed Dec 16 2015 03:07 pm

It basically lets others know what new files your system received that day, without having to connect to your BBS on a daily basis. All other tickers out there do it, so please don't shoot the messenger.

I'm trying to better understand it... so the idea is that you post a message to a networked sub so that your users won't call your BBS or that users will call your BBS, download a file, and disconnect? And this is something Sysops want?

If the system (like mine, and a bunch of others I know of) manually move files around using scripts, as well as some kind of FREQ handler, then I don't doubt at all that the files are available via FREQ. YMMV.

I tried a few FREQs... no files have been recieved yet. I didn't try your BBS or others that appeared likely to actually work. Maybe I should try one to make sure a FREQ works at all I suppose.

As for stat reporting stuff, it makes more sense to report *all* files rather than just ones that came in via an FDS. This would be a very different script... and again, does not belong in ticit.js.

Reporting ALL files on a daily basis? I don't think that's what the announce message was intended for whatsoever.

Sorry, I meant all new files... not just ones that came via FDS.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

exec tickit.js 1.7 1.8
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv8090

Modified Files:
tickit.js
Log Message:
Explicitly check for empty and undefined passwords and match them to no
PKTPWD line.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Hello Deuce,

On 17 Dec 15 10:49, Deuce wrote to Accession:

It basically lets others know what new files your system received
that day, without having to connect to your BBS on a daily basis.
All other tickers out there do it, so please don't shoot the
messenger.

I'm trying to better understand it... so the idea is that you post a message to a networked sub so that your users won't call your BBS or
that users will call your BBS, download a file, and disconnect? And
this is something Sysops want?

Not so much. More like it let's people that *don't* call your BBS know what files were processed by your TIC processor that day. If one of those files may happen to interest them, maybe they would call for the first time to grab it..?

I don't know. You can probably look at it a half of a dozen ways.

If the system (like mine, and a bunch of others I know of) manually
move files around using scripts, as well as some kind of FREQ
handler, then I don't doubt at all that the files are available
via FREQ. YMMV.

I tried a few FREQs... no files have been recieved yet. I didn't try
your BBS or others that appeared likely to actually work. Maybe I
should try one to make sure a FREQ works at all I suppose.

In order for my FREQ processor to work, the file I receive here must have the .REQ extension. Some people try sending regular netmails or .MSG, and it won't work with that.

Reporting ALL files on a daily basis? I don't think that's what the
announce message was intended for whatsoever.

Sorry, I meant all new files... not just ones that came via FDS.

That would be fine as well. If there were something to handle that, it may even
be a better idea. Most of these tic processors are 3rd party utilities, so they
do their own announcements.

Since yours is only going to be used with Synchronet, the sky's the limit.

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Hello Deuce,

On 17 Dec 15 10:36, Deuce wrote to Accession:

What's already done is done. I've been using TIC passwords for
years now for *some* inkling of security. I felt that with the use
of a CRAM-MD5 encrypted binkp connection, there was no need for
packet password.

Why do/did you feel that fire transfers need some extra "security",
but packets don't?

Because files can contain executables, which can contain a virus. The worst you
can do with a message packet is bomb someone with a 512mb sized one, as has happened in the past in Fidonet.

Before my tic processor runs, I also run a daily updated clamAV on those received files, whereas message bundles don't need that either.

Honestly, what I would end up suggesting if all your links are binkp
is to simply drop the TICK password just like you did the packet
password rather than add a packet password. It really doesn't add any extra security at all unless the system is misconfigured.

Ok.

Again, you must not have read what I wrote correctly.

Or it was worded poorly.

While my opinion on the matter may be biased, I specifically re-read what I wrote to you, and what you replied with, and you seemed to have conjured up some things I said that I never did. So there's also the possibility that my messages to you were received poorly.

Mayhaps we should just agree to disagree.

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Re: Re: exec/tickit.js
By: Accession to Deuce on Thu Dec 17 2015 05:16 pm

Sorry, I meant all new files... not just ones that came via FDS.

That would be fine as well. If there were something to handle that, it may even be a better idea. Most of these tic processors are 3rd party utilities, so they do their own announcements.

If anyone is actually interested in this, let me know. It's a trivial script to write, but I'm not sure anyone wants it.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: exec/tickit.js
By: Accession to Deuce on Thu Dec 17 2015 05:22 pm

What's already done is done. I've been using TIC passwords for
years now for *some* inkling of security. I felt that with the use
of a CRAM-MD5 encrypted binkp connection, there was no need for
packet password.

Why do/did you feel that fire transfers need some extra "security",
but packets don't?

Because files can contain executables, which can contain a virus. The worst you
can do with a message packet is bomb someone with a 512mb sized one, as has happened in the past in Fidonet.

Well, there's also the impersonation angle. Not sure how a TICK password will help protect against a virus... and your system shouldn't be running files it gets.

But the point is that since there's a binkp authentication, having the TICK processor *also* verify that the other end is who they say they are adds nothing except a password in plain text. In the not unusual case where the TICK password and binkp password are the same, this actually lowers security.

Before my tic processor runs, I also run a daily updated clamAV on those received files, whereas message bundles don't need that either.

Yeah, this is clearly a good idea.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Hello Deuce!

17 Dec 15 17:39, you wrote to Accession:

But the point is that since there's a binkp authentication, having the TICK processor *also* verify that the other end is who they say they
are adds nothing except a password in plain text. In the not unusual
case where the TICK password and binkp password are the same, this actually lowers security.

Every network I participate in uses TIC passwords. These are set up as extra "security" between the uplink and the downlink. New passwords are placed in the
newly generated TIC file for the next downlink(s), and the next, etc. It is similar to a session password with Binkd and even EMSI, etc. I use HTICK and if
the password in the TIC file doesn't match what I have configured in the HTICK config file, it fails and renames the *.TIC file to *.BAD. I guess that is similar to a packet password...

Keep up the good work. New "features" are always welcome.


Ray


--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: Ray's Road Node - Somewhere in California. (1:214/23)
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Hello Deuce,

On 17 Dec 15 17:28, Deuce wrote to Accession:

Re: Re: exec/tickit.js
By: Accession to Deuce on Thu Dec 17 2015 05:16 pm

Sorry, I meant all new files... not just ones that came via

FDS.

That would be fine as well. If there were something to handle that,
it may even be a better idea. Most of these tic processors are 3rd
party utilities, so they do their own announcements.

If anyone is actually interested in this, let me know. It's a trivial script to write, but I'm not sure anyone wants it.

I probably would switch over to a new native Synchronet feature it it did all the things my current software does. So I would definitely vote yes on that, as
well as tickit.js being able to forward to downlinks, which is why I stopped using Tinytic a couple years back.

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Hello Deuce,

On 17 Dec 15 17:39, Deuce wrote to Accession:

Because files can contain executables, which can contain a virus.
The worst you can do with a message packet is bomb someone with a
512mb sized one, as has happened in the past in Fidonet.

Well, there's also the impersonation angle. Not sure how a TICK
password will help protect against a virus... and your system
shouldn't be running files it gets.

True, but I tend to worry more about security when a file that could possibly contain an executable is passed on from my system to many others. That's really
my only reasoning for adding the TIC password as well as running AV on them.

But the point is that since there's a binkp authentication, having the TICK processor *also* verify that the other end is who they say they
are adds nothing except a password in plain text. In the not unusual
case where the TICK password and binkp password are the same, this actually lowers security.

Sure, but isn't that specific TIC password only processed in plain text locally
with one's tic processor? It's not transmitted over a connection or anything (except inside the file). Or am I understanding that wrong?

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Re: exec/tickit.js
By: Ray Quinn to Deuce on Fri Dec 18 2015 05:17 am

Every network I participate in uses TIC passwords. These are set up as extra "security" between the uplink and the downlink. New passwords are placed in the
newly generated TIC file for the next downlink(s), and the next, etc. It is similar to a session password with Binkd and even EMSI, etc. I use HTICK and if
the password in the TIC file doesn't match what I have configured in the HTICK config file, it fails and renames the *.TIC file to *.BAD. I guess that is similar to a packet password...

It is the same as a packet password. Do your networks not set a packet password, but do set a TICK password? If so, does anyone know why, or is it just a "we've always done it this way, so this is the way we do it."

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: exec/tickit.js
By: Accession to Deuce on Fri Dec 18 2015 04:28 pm

That would be fine as well. If there were something to handle that,
it may even be a better idea. Most of these tic processors are 3rd
party utilities, so they do their own announcements.

If anyone is actually interested in this, let me know. It's a trivial script to write, but I'm not sure anyone wants it.

I probably would switch over to a new native Synchronet feature it it did all the things my current software does. So I would definitely vote yes on that, as
well as tickit.js being able to forward to downlinks, which is why I stopped using Tinytic a couple years back.

So basically a script that will generate a (customizable) list of new files since the last time it ran or the specified period in a configured set of areas?

As for tickit.js forwarding, I'll take a look at that... it would likely be FLO style only (at least initially) and I'm not sure I've heard a convincing argument to support separate TICK/Packet passwords, so that "feature" would likely not be a priority either.

Simple FLO forwarding using the existing configs may be easily doable.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: exec/tickit.js
By: Accession to Deuce on Fri Dec 18 2015 04:34 pm

But the point is that since there's a binkp authentication, having the TICK processor *also* verify that the other end is who they say they are adds nothing except a password in plain text. In the not unusual case where the TICK password and binkp password are the same, this actually lowers security.

Sure, but isn't that specific TIC password only processed in plain text locally
with one's tic processor? It's not transmitted over a connection or anything (except inside the file). Or am I understanding that wrong?

The password is only in the TIC file from source to destination in plaintext in the transferred file.

If using a non-encrypted binkp connection (CRAM-MD5 and crypt are different features), the password gets transmitted in plain text over the socket (as part of the file).

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Hello Deuce,

On 18 Dec 15 18:17, Deuce wrote to Accession:

I probably would switch over to a new native Synchronet feature it
it did all the things my current software does. So I would
definitely vote yes on that, as well as tickit.js being able to
forward to downlinks, which is why I stopped using Tinytic a couple
years back.

So basically a script that will generate a (customizable) list of new files since the last time it ran or the specified period in a
configured set of areas?

Sure, including everything that was TIC'd and uploaded via the BBS, definitely.
Or an option to either post it directly to a Synchronet message base, or drop the results to a text file to be inserted via smbutil. Either or..

As for tickit.js forwarding, I'll take a look at that... it would
likely be FLO style only (at least initially) and I'm not sure I've
heard a convincing argument to support separate TICK/Packet passwords,
so that "feature" would likely not be a priority either.

You may get some flack from the people using the old file attach mailers, but..
I've known you for awhile, and you've only dealt with binkp for quite some time
now. In my case, I wouldn't be worried about that.

Although I do still ask for a separate sbbsecho.cfg option. TICPWD could be separate from PKTPWD only for people that are file security nincompoops. :)

Simple FLO forwarding using the existing configs may be easily doable.

Right on!

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Hello Deuce,

On 18 Dec 15 18:20, Deuce wrote to Accession:

Sure, but isn't that specific TIC password only processed in plain
text locally with one's tic processor? It's not transmitted over a
connection or anything (except inside the file). Or am I
understanding that wrong?

The password is only in the TIC file from source to destination in plaintext in the transferred file.

If using a non-encrypted binkp connection (CRAM-MD5 and crypt are different features), the password gets transmitted in plain text over
the socket (as part of the file).

I request at the VERY LEAST cram-md5 for the binkp connection. I think just about all of my 70+ connections have been able to do that. Ones running older mailers may not have that option, and for those specific to that I've made accomodations.

With that said, Synchronet is able to handle what you throw at it. So I thank you and Rob for that, of course. And when you come out with a new feature that could potentially be usable to me without having to use 3rd party stuff.. I will nitpick at it until I can actually feel good using it. :D :D :D

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Re: Re: exec/tickit.js
By: Accession to Deuce on Fri Dec 18 2015 09:58 pm

As for tickit.js forwarding, I'll take a look at that... it would likely be FLO style only (at least initially) and I'm not sure I've heard a convincing argument to support separate TICK/Packet passwords, so that "feature" would likely not be a priority either.

You may get some flack from the people using the old file attach mailers, but.. I've known you for awhile, and you've only dealt with binkp for quite some time now. In my case, I wouldn't be worried about that.

The main issue with supporting attach style is that I wouldn't be able to test it... and I know that FidoNuts hate it any time some new software appears on their network doing something they don't expect.

Although I do still ask for a separate sbbsecho.cfg option. TICPWD could be separate from PKTPWD only for people that are file security nincompoops. :)

Yeah, until someone gives me a reason that makes sense, this is going to stay a "no". FidoNet has a lot of stupid due to lack of understanding and fear of breaking some TRS-80 mailer. I'll not contribute to that culture.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: exec/tickit.js
By: Accession to Deuce on Fri Dec 18 2015 10:03 pm

If using a non-encrypted binkp connection (CRAM-MD5 and crypt are different features), the password gets transmitted in plain text over the socket (as part of the file).

I request at the VERY LEAST cram-md5 for the binkp connection. I think just about all of my 70+ connections have been able to do that. Ones running older mailers may not have that option, and for those specific to that I've made accomodations.

Do you ensure that the binkp password is different to the TIC password? 'cause if not, the TIC password is a huge security hole. Same with the Areafix password.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

exec tickit.js 1.8 1.9
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv16266

Modified Files:
tickit.js
Log Message:
Don't return false if no pktpass line matches the node so that the test
for empty/undefined can occur.



---

exec tickit.js 1.9 1.10
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv18885

Modified Files:
tickit.js
Log Message:
Re-organize the INI file laout and prepare to support downlinks.



---
þ Synchronet þ Vertrauen þ Home of Syn

exec tickit.js 1.10 1.11
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv21930

Modified Files:
tickit.js
Log Message:
If we can't move the file to the final location, fail processing and don't delete the TIC file.



---
þ Syn

exec tickit.js 1.11 1.12
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv26138

Modified Files:
tickit.js
Log Message:
Add circular path detection and file forwarding.
This could now be considered "full featured" since there's no more features
I currently plan on adding.

Have at 'er!



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.13 1.14
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv8621

Modified Files:
tickit.js
Log Message:
Add a "how to set up" comment at the start... this info will go on the Wiki
as well.



---
þ Synchronet þ Ve

exec tickit.js 1.14 1.15
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv5437

Modified Files:
tickit.js
Log Message:
Add all our fidonet addresses to the seen by list when forwarding TIC files.



---
þ Synchronet þ Vertrauen þ

exec tickit.js 1.15 1.16
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv7027

Modified Files:
tickit.js
Log Message:
Bugfix: Put Seenby addresses in Seenby lines, not Path lines (eek!)


---
þ Synchronet þ Vertrauen þ Home of Sy

exec tickit.js 1.16 1.17
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv8970

Modified Files:
tickit.js
Log Message:
Fix address parsing and outbound path calculation.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ teln

exec tickit.js 1.17 1.18
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv17880

Modified Files:
tickit.js
Log Message:
Add support for points, and create the outbound directory (using mkpath()) if it doesn't exist.


---
þ Synch

exec tickit.js 1.19 1.20
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv13859

Modified Files:
tickit.js
Log Message:
Fix typo in error message.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.20 1.21
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv4452

Modified Files:
tickit.js
Log Message:
Fix bug in forwarding TIC files reported by DeepEND.
Thanks!


---
þ Synchronet þ Vertrauen þ Home of Synchron

exec tickit.js 1.21 1.22
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv27820

Modified Files:
tickit.js
Log Message:
Bugfix: Description offset comes before the size offset.
Thanks for the report!



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.22 1.23
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv18428

Modified Files:
tickit.js
Log Message:
Use String.repeat() instead of a fixes string... it looks like there may have been an extra space in there.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.23 1.24
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv12880

Modified Files:
tickit.js
Log Message:
Polyfill the String.prototype.repeat() method.
Some better polyfill method should be worked out at some point...


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.24 1.25
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv13191

Modified Files:
tickit.js
Log Message:
Filenames are 12 characters long, not 11 (the dot is included).



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: exec/tickit.js
By: deuce to CVS commit on Thu Jan 28 2016 13:02:10

Modified Files:
tickit.js
Log Message:
Filenames are 12 characters long, not 11 (the dot is included).

If it is DOS format (8-3) and you include the dot, then it would be 13 I think, Unless I am out in left field someplace, and thinking about something completely different <G>
--- SBBSecho 2.33-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: exec/tickit.js
By: Joe Delahaye to deuce on Thu Jan 28 2016 07:01 pm

Filenames are 12 characters long, not 11 (the dot is included).

If it is DOS format (8-3) and you include the dot, then it would be 13 I think, Unless I am out in left field someplace, and thinking about something completely different <G>

8+3+strlen(".") == 12.

I think you're thinking about something different. :-)

---
þ Synchronet þ The future of BBSing

Hello Joe,

On 28 Jan 16 19:01, Joe Delahaye wrote to deuce:

If it is DOS format (8-3) and you include the dot, then it would be 13
I think, Unless I am out in left field someplace, and thinking about something completely different <G>

I demand a recount! :)

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20151129
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Re: exec/tickit.js
By: Deuce to Joe Delahaye on Fri Jan 29 2016 02:06:41

If it is DOS format (8-3) and you include the dot, then it would be 13
I think, Unless I am out in left field someplace, and thinking about
something completely different <G>

8+3+strlen(".") == 12.

I think you're thinking about something different. :-)

Actually, I'm mis counting :( Shame on me.
--- SBBSecho 2.33-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Re: exec/tickit.js
By: Accession to Joe Delahaye on Thu Jan 28 2016 20:10:48

If it is DOS format (8-3) and you include the dot, then it would be
13 I think, Unless I am out in left field someplace, and thinking
about something completely different <G>

I demand a recount! :)

You got it <G>
--- SBBSecho 2.33-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.25 1.26
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv5783

Modified Files:
tickit.js
Log Message:
Add correct handling for Replaces line.
If Replaces is the same as the new filename, replace it. Otherwise, return
and error and process the next TIC file.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.26 1.27
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv7888

Modified Files:
tickit.js
Log Message:
Return false when logging an error about a lack of a replaces line.
Should prevent TIC file from being incorrectly deleted.

Thanks drakahn99!


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.27 1.28
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv12073

Modified Files:
tickit.js
Log Message:
Re-order load()s


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.28 1.29
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv31883

Modified Files:
tickit.js
Log Message:
Support multiple Desc lines as an Ldesc replacement.

Despite what fsp-1039.001 says, ALLFIX uses multiple Desc lines for long descriptions, so Desc is *not* "A one line description of the file to be distributed." and actually matches the Ldesc description.

Support both, but use the longest one.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.29 1.30
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv517

Modified Files:
tickit.js
Log Message:
Add a new IgnorePassword global key to tickit.ini to completely ignore all
TIC passwords and not care if they match the packet password or not.

This imports *ALL* TIC files into the local file base, possibly overriding existing files, so could be dangerous if you accept incoming TIC files from anybody (which is the normal Fido setup).



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.30 1.31
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv1045

Modified Files:
tickit.js
Log Message:
Add SecureOnly option to global tickit.ini config

This will only import tic files from the secure inbound. This is intended to be used with IgnorePassword to limit the attack surface.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.31 1.32
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv3064

Modified Files:
tickit.js
Log Message:
If the file from a TIC already exists, use wildmatch() on Replaces to see
if it should be replaced. It's common on FidoNet for replaces to have a wildcard in it.

Also, add support for a new Handler key in tickit.ini. This defines a file which defines a Handle_TIC function and whose last statement isn't null.
The parsed TIC file is passed to this function and, if it returns true, the file is assumed to be handled.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.32 1.33
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv28996

Modified Files:
tickit.js
Log Message:
Fix error in previous commit.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.33 1.34
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv31646

Modified Files:
tickit.js
Log Message:
Remove extraneous semi-colon



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.34 1.35
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv20343

Modified Files:
tickit.js
Log Message:
Add support for a HandlerArg string to be passed to a handler.
Run the handler in a try/catch and log exceptions.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.35 1.36
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv12743

Modified Files:
tickit.js
Log Message:
Fix desc/longdesc parsing which added "undefined" to the beginning of the description.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.36 1.37
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv13333

Modified Files:
tickit.js
Log Message:
If the handler failes or returns false, continue normal processing.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.37 1.38
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv13402

Modified Files:
tickit.js
Log Message:
Typo in last commit



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

exec tickit.js 1.38 1.39
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv13563

Modified Files:
tickit.js
Log Message:
Nelgin's mod to add separate TIC File password support.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.39 1.40
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv1233

Modified Files:
tickit.js
Log Message:
Initialize the tic desc to an empty string since it's later assumed to
be defined.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.40 1.41
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv2302

Modified Files:
tickit.js
Log Message:
Don't strip leading whitespace from "desc" and "ldesc" lines.

A lot of LDesc stuff has leading whitespace.



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.41 1.42
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv28572

Modified Files:
tickit.js
Log Message:
Experimental feature for bgdjr: when '-replace' argument is passed on the command-line, treat all .TIC files as they have have a "REPLACES" clause.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 2018 Apr 02 13:32:12, you wrote to CVS commit:

exec tickit.js 1.41 1.42
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv28572

Modified Files:
tickit.js
Log Message:
Experimental feature for bgdjr: when '-replace' argument is passed on the command-line, treat all .TIC files as they have have a "REPLACES" clause.

might want to call that "-forcereplace" or similar... most other FTN file processors use something like "-replace" to enable replacing IF the TIC has the
REPLACES verb in it... some sysops do not want the older files replaced automatically so their processor has an option to ignore the REPLACES verb... in some cases, following REPLACES in some areas and ignoring it in others is a good thing so some processors may make this option a per area setting...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... You know. That old guy who carried moderation to excess.
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.42 1.43
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv10683

Modified Files:
tickit.js
Log Message:
Change the -replace option to -force-replace since the old "tick" program
had a "replace" option that did something differnet (enabled parsing of the REPLACES verb) - don't want to confuse sysops now. :-)


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.43 1.44
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv17047

Modified Files:
tickit.js
Log Message:
Simplified the rename_or_move() function:
- Don't use the deprecated 'e' file open mode
- Use the global file_copy() method rather than roll-your-own


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.45 1.46
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv17812

Modified Files:
tickit.js
Log Message:
seem like maybe addrs should be a array


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

rswindell wrote:

exec tickit.js 1.41 1.42
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv28572

Modified Files:
tickit.js
Log Message:
Experimental feature for bgdjr: when '-replace' argument is passed on the command-line, treat all .TIC files as they have have a "REPLACES" clause.

This might stop me ripping Gert a new rear end. I'm sure sure how he's managed to get away with creating nodelists for his networks for so long and not had to put replace lines in them. I can't be the only one. This will certainly help out
though it'd helf if we could specify which file areas should force replace and which shouldn't.

---
þ Synchronet þ End Of The Line BBS - endofthelinebbs.com

Re: Re: exec/tickit.js
By: Nelgin to rswindell on Tue Aug 14 2018 03:47 pm

This might stop me ripping Gert a new rear end. I'm sure sure how he's managed to get away with creating nodelists for his networks for so long and not had to put replace lines in them. I can't be the only one. This will certainly help out though it'd helf if we could specify which file areas should force replace and which shouldn't.

It would certainly be better if those who hatch files would use the replaces line when needed.

I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in those areas anyway.. :)

Ttyl :-),
Al


... Don't blame me.. I didn't vote Conservative!

---
þ Synchronet þ The Rusty MailBox - Penticton, BC Canada

Re: Re: exec/tickit.js
By: Al to Nelgin on Tue Aug 14 2018 04:13 pm

I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in those areas anyway.. :)

Someone actually uses the delfiles utility? Good to know. :-)

digital man

Synchronet "Real Fact" #94:
Synchronet v3.15b was released in October of 2011 (5 years after v3.14a). Norco, CA WX: 79.7øF, 50.0% humidity, 10 mph E wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 08-14-18 15:47, Nelgin wrote to rswindell <=-

This might stop me ripping Gert a new rear end. I'm sure sure how he's managed to get away with creating nodelists for his networks for so
long and not had to put replace lines in them. I can't be the only one. This will certainly help out though it'd helf if we could specify which file areas should force replace and which shouldn't.

I use Replaces in my nodelist and infopack distribution. Only issue I'm having is TickIT keeping the old nodelist around, but it is replacing the infopack, which is the same filename each time.


... Hard work has a future payoff. Laziness pays off now.
--- MultiMail/Win v0.51
þ Synchronet þ Freeway BBS, Bendigo Australia. freeway.apana.org.au

Re: Re: exec/tickit.js
By: Digital Man to Al on Tue Aug 14 2018 06:59 pm

Re: Re: exec/tickit.js
By: Al to Nelgin on Tue Aug 14 2018 04:13 pm

I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in those areas anyway.. :)

Someone actually uses the delfiles utility? Good to know. :-)

yes, if we have files we use delfiles.
---
þ Synchronet þ ::: BBSES.info - free BBS services :::

Al wrote:

Re: Re: exec/tickit.js
By: Nelgin to rswindell on Tue Aug 14 2018 03:47 pm

This might stop me ripping Gert a new rear end. I'm sure sure how he's
managed to get away with creating nodelists for his networks for so long
and not had to put replace lines in them. I can't be the only one. This
will certainly help out though it'd helf if we could specify which file
areas should force replace and which shouldn't.

It would certainly be better if those who hatch files would use the replaces line when needed.

I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in
those areas anyway.. :)

I've been following a sort of side conversation on that. Janis has been giving some hints on how to hack files with a Replaces line.

Personally, from what I am seeing of the new ZC, I don't much care for his attitude.

---
þ Synchronet þ End Of The Line BBS - endofthelinebbs.com

Re: Re: exec/tickit.js
By: Vk3jed to Nelgin on Wed Aug 15 2018 11:48 am

I use Replaces in my nodelist and infopack distribution. Only issue I'm having is TickIT keeping the old nodelist around, but it is replacing the infopack, which is the same filename each time.

I read your comment on this a couple weeks ago and I see it here too. When a new nodelist.z07 comes in and replaces nodelist.z00 the nodelist.z00 isn't removed. Tickit might need a tweak.

Ttyl :-),
Al


... Plagiarism prohibited, derive carefully.

---
þ Synchronet þ The Rusty MailBox - Penticton, BC Canada

Re: Re: exec/tickit.js
By: Nelgin to Al on Tue Aug 14 2018 10:02 pm

I've been following a sort of side conversation on that. Janis has been giving some hints on how to hack files with a Replaces line.

That's not good. We have to be able to trust that the tics we receive are what the hatching node created, especially when those tics are going to replace files. They should have path and seen bys added but otherwise not modified.

Personally, from what I am seeing of the new ZC, I don't much care for his attitude.

The important thing is what he does as ZC. His main duty is to create and distribute the nodelist (along with his other zone partners). As far as I have seen he does a good job of that although I think his tics could use a replaces line.

I always thought those tics had a replaces line but I could be mistaken.. ;)

I hope that whatever he does as ZC will build up fidonet and not tear it down.

Ttyl :-),
Al


... My spelling? Oh, it's just line noise.

---
þ Synchronet þ The Rusty MailBox - Penticton, BC Canada

Al wrote:

I always thought those tics had a replaces line but I could be mistaken.. ;)

As Janis wrote, "does anyone in Zone 1 or 2 know how to create a tic with Replaces other than me?" lol. Or something like that.

Follow the conversation on FN_SYSOP I think it is.

---
þ Synchronet þ End Of The Line BBS - endofthelinebbs.com

Nelgin wrote:

Al wrote:

I always thought those tics had a replaces line but I could be mistaken.. ;)

As Janis wrote, "does anyone in Zone 1 or 2 know how to create a tic with Replaces other than me?" lol. Or something like that.

Follow the conversation on FN_SYSOP I think it is.

Correction Z1C echo group.

---
þ Synchronet þ End Of The Line BBS - endofthelinebbs.com

Re: Re: exec/tickit.js
By: Nelgin to Al on Wed Aug 15 2018 12:31 am

As Janis wrote, "does anyone in Zone 1 or 2 know how to create a tic with Replaces other than me?" lol. Or something like that.

Follow the conversation on FN_SYSOP I think it is.

I haven't seen it but I usually "T" my way through there. I'll have a look.

Ttyl :-),
Al


... All wiyht. Rho sritched mg kegtops awound?

---
þ Synchronet þ The Rusty MailBox - Penticton, BC Canada

On 08-14-18 20:41, Al wrote to Vk3jed <=-

I read your comment on this a couple weeks ago and I see it here too.
When a new nodelist.z07 comes in and replaces nodelist.z00 the nodelist.z00 isn't removed. Tickit might need a tweak.

Yes, that's what I'm seeing here. :) It's not my TIC files, because Mystic removes the old nodelist when it does its import.


... Bad Restaurant: Hospital map on the back of the menu.
--- MultiMail/Win v0.51
þ Synchronet þ Freeway BBS, Bendigo Australia. freeway.apana.org.au

Digital Man wrote to Al on 08-14-18 18:59 <=-

Re: Re: exec/tickit.js
By: Al to Nelgin on Tue Aug 14 2018 04:13 pm

I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in those areas anyway.. :)

Someone actually uses the delfiles utility? Good to know. :-)

lol... I just used it this morning... :)


--

Bill

Telnet: tequilamockingbirdonline.net
Web: bbs.tequilamockingbirdonline.net
FTP: ftp.tequilamockingbirdonline.net:2121
IRC: irc.tequilamockingbirdonline.net Ports: 6661-6670 SSL: +6697
Radio: radio.tequilamockingbirdonline.net:8010/live


... Look Twice... Save a Life!!! Motorcycles are Everywhere!!!
--- MultiMail/Win32 v0.50
þ Synchronet þ TequilaMockingbird Online - Toms River, NJ

Al wrote:

Re: Re: exec/tickit.js
By: Nelgin to rswindell on Tue Aug 14 2018 03:47 pm

This might stop me ripping Gert a new rear end. I'm sure sure how he's
managed to get away with creating nodelists for his networks for so long
and not had to put replace lines in them. I can't be the only one. This
will certainly help out though it'd helf if we could specify which file
areas should force replace and which shouldn't.

It would certainly be better if those who hatch files would use the replaces line when needed.

I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in
those areas anyway.. :)

What options are you using for delfiles? I'd hate to get it wrong!

I assume you're calling it once per day from the timed events menu option?

---
þ Synchronet þ End Of The Line BBS - endofthelinebbs.com

Re: Re: exec/tickit.js
By: Nelgin to Al on Wed Aug 15 2018 12:00 pm

What options are you using for delfiles? I'd hate to get it wrong!

Yes, we don't want any errors there.. :)

I only used the -LIB option to point to the fido area. I only have a few areas set to delete old files so it will only do anything there.

I assume you're calling it once per day from the timed events menu option?

I am planning on adding it as a weekly event but I just did it once from the command line.

But wait a minute! A few have asked Z1C to use the replaces verb in tic files. If he does then there is no need to do that. There is probably no need to keep so many old nodelists but I like to keep them around just in case I need to look something up in an old list.

Ttyl :-),
Al


... "All these doughnuts and not a cop in sight" -- Plucky Duck

---
þ Synchronet þ The Rusty MailBox - Penticton, BC Canada

Al wrote:

But wait a minute! A few have asked Z1C to use the replaces verb in tic files.
If he does then there is no need to do that. There is probably no need to keep
so many old nodelists but I like to keep them around just in case I need to look something up in an old list.

And he said that it has been done so we'll find out tomorrow.

---
þ Synchronet þ End Of The Line BBS - endofthelinebbs.com

exec tickit.js 1.46 1.47
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv21424

Modified Files:
tickit.js
Log Message:
Nelgin's mod (cleaned-up):
If a tickit.ini area section has "ForceReplace=true", then it'll treat
all the incoming .tic files for that area as though they have a "Replaces" keyword.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.47 1.48
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv17769

Modified Files:
tickit.js
Log Message:
Added support for an 'uploader' TickIt global option. If specified, this
value will be passed as the '-x' parameter (uploader) value to addfiles
when adding files to filebases.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.48 1.49
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv32518

Modified Files:
tickit.js
Log Message:
Make the 'no matching replaces line' error more descriptive.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.49 1.50
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv32717

Modified Files:
tickit.js
Log Message:
Don't assume the link's gender. This may be a sausagefest but we can
always pretend otherwise.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.50 1.51
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv2674

Modified Files:
tickit.js
Log Message:
Different log messages for absent vs. mismatched Replaces line.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.51 1.52
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv2898

Modified Files:
tickit.js
Log Message:
Unmisplace misplaced quotation mark in addfiles command line for uploader's name.
Spotted and fixed by Mark Lewis.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.53 1.54
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv18484

Modified Files:
tickit.js
Log Message:
add lost code to write existing Path lines to the TIC file - wkitty42


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.54 1.55
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv363

Modified Files:
tickit.js
Log Message:
Handle case mismatches with filenames.
I actually made this change back in January, but I don't remember why/who-for.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

exec tickit.js 1.55 1.56
Update of /cvsroot/sbbs/exec
In directory cvs:/tmp/cvs-serv24565

Modified Files:
tickit.js
Log Message:
For Ragnarok, use the linked-node's crash/hold/normal/direct status configuration when determining the created/appended FLO filename extension.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/25a1b75dfed6766656d89e90
Modified Files:
exec/tickit.js
Log Message:
Use -debug command-line option if you want the <area> using ... address log

For Nelgin, to reduce log spam.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e0d937bbd5b7843d18b3eda6
Modified Files:
exec/tickit.js
Log Message:
Don't allow duplicate extended and normal descriptions

If the extended description and the normal (short) description are the same, delete the extended (long) description.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/eb6034666fc5d68b6ea5d126
Modified Files:
exec/tickit.js
Log Message:
Change log level of "already exists" log messages from ERROR to WARNING

Fix issue #773
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e86b0a106586fc6c0f662dc4
Modified Files:
exec/tickit.js
Log Message:
Strip trailing whitespace off end of values read from .tic files

Fix issue #785
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net