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.
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?
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.
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.
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?)
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 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.
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.
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
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.
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.
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?
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.
Again, you must not have read what I wrote correctly.
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.
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.
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.
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.
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.
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.
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.
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.
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 viaFDS.
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.
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.
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...
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.
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?
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.
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).
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. :)
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.
Modified Files:
tickit.js
Log Message:
Filenames are 12 characters long, not 11 (the dot is included).
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>
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>
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. :-)
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! :)
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.
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.
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.. :)
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.
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. :-)
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 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'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.
I always thought those tics had a replaces line but I could be mistaken.. ;)
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.
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.
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.
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. :-)
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?
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.
Sysop: | MCMLXXIX |
---|---|
Location: | Prospect, CT |
Users: | 325 |
Nodes: | 10 (0 / 10) |
Uptime: | 138:42:48 |
Calls: | 502 |
Calls today: | 1 |
Messages: | 218443 |