Hi,
It has been mentioned elsewhere and maybe a while back too but I'm not quite sure when DECnet (VAX/VMS 7.3) started serving up jewels like:
%%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%%
Message from user DECNET on TUPILE
DECnet event 4.10, circuit up
From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64
Circuit UNA-0
Regards
Keith
I was just made aware that there is a bug in the proxy access handling
under RSX.
If you enable incoming proxy access, but do not have a proxy database
set up, RSX will actually allow remote users to gain access to files (or
whatever) as any user they specify, without having to give any password.
This is a bug in the network verification program. I just fixed this,
and a fixed version is available on MIM::LB:[5,54]NVPFSL.TSK. People
should be able to just copy that one over, and then either remove NVP...
and then install LB:[5,54]NVPFSL, or just reboot, and the fixed version
should be active.
You can verify if you have the correct version by checking the version
of NVP, like this:
.tas nvp...
NVP... V08.20 GEN 150. 00021400 DU0:-00012167042
.
The fixed version is V08.20.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
[I previously sent this reply from an email address not registered
on this list, so presumaby it got bit-binned.]
On 2024-11-13 14:20, Paul Koning wrote:
> By "bug" I meant "specification bug". The author of the DNA NetMan
> spec messed up here. Yes, VMS faithfully follows that bad design.
>
> The bugfix amounts to fixing the text of the spec, then changing the
> implementations to match the corrected text. I don't know if the
> former has ever been done but obviously a number of DECnet
> implementations acted as if had been. :-)
I have Alpha VMS listings kits, but stupidly gave away my VAX listings.
Should someone send me a pointer to where a 7.3 listings kit can be
found, I'll try to find and fix it when I get back from vacation next
month.
On VMS, DECnet is a System Integrated Product (SIP) so it _should_ be
in the listings kit, but no guarantees.
Yes, I do have a listings license and had VAX/VMS on support at the
time V7.3 came out, so if someone wants me to "show my papers" be-
fore they'll give me access, I can do that...
>> On Nov 13, 2024, at 1:53 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
>>
>> I would not call it a bug. It was initially defined that way. However,
>> RSX officially decided to start treating it as an unsigned 16-bit
>> value with the last releases, and documented this.
>>
>> And it's a change that do make sense.
>>
>> But if others have not applied the same update, then it makes sense
>> that they would zero the value if it have the high bit set.
>>
>> Johnny
>>
>> On 2024-11-13 19:26, Paul Koning wrote:
>>> The statement in the DECnet spec that julian half-day is 15 bits is
>>> an obvious bug with an obvious fix; clearly RSX and others have made
>>> that fix. VMS needs to do likewise.
>>> paul
>>>> On Nov 13, 2024, at 12:50 PM, John Forecast <john(a)forecast.name
>>>> <mailto:john@forecast.name>> wrote:
>>>>
>>>> Depends on the implementation. Nov 9, 2021 on VMS, Ultrix and
>>>> probably some others. RSX is good until 2065.
>>>>
>>>> John.
>>>>
>>>>> On Nov 13, 2024, at 10:24 AM, Keith Halewood
>>>>> <Keith.Halewood(a)pitbulluk.org
>>>>> <mailto:Keith.Halewood@pitbulluk.org>> wrote:
>>>>>
>>>>> Hi,
>>>>> It has been mentioned elsewhere and maybe a while back too but I’m
>>>>> not quite sure when DECnet (VAX/VMS 7.3) started serving up jewels
>>>>> like:
>>>>> %%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%%
>>>>> Message from user DECNET on TUPILE
>>>>> DECnet event 4.10, circuit up
>>>>> From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64
>>>>> Circuit UNA-0
>>>>> Regards
>>>>> Keith
>>>>> _______________________________________________
>>>>> HECnet mailing list --hecnet(a)lists.dfupdate.se
>>>>> <mailto:hecnet@lists.dfupdate.se>
>>>>> To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
>>>>> <mailto:hecnet-leave@lists.dfupdate.se>
>>>>
>>>> _______________________________________________
>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>>>> <mailto:hecnet@lists.dfupdate.se>
>>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>>> <mailto:hecnet-leave@lists.dfupdate.se>
>>> _______________________________________________
>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>
>> --
>> Johnny Billquist || "I'm on a bus
>> || on a psychedelic trip
>> email: bqt(a)softjar.se || Reading murder books
>> pdp is alive! || tryin' to stay hip" - B. Idol
>> _______________________________________________
>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
I've gotten far enough along with the Tops-20 finger server that I
thought it would be a good idea to capture some of the common
assumptions and requirements into a DECnet finger specification document
of a sorts. The current working version can be found at:
_VENTI2::DECNET-FINGER-SPECIFICATION.TXT_.
I emphasize /WORKING VERSION/ as I have been working with (a very
patient) Johnny to run tests, and chase down documentation bugs, gaps,
inaccuracies and other delusions. It's an active work in progress.
In particular, the limits of certain connections field are based what is
documented in the January 1980 version of the TOPS-20 DECnet-20
Programmer's Guide and Operations Manual, Order Number AA-5091A-TM.
This is quite old as it is based on Tops-20 version 4 and Tops-20 DECnet
version 2. However, it is what I had handy and what I remember coding
to, back in the day. Connection parameters are partially specified as
attributes and are as follows:
* ;*USERID*:/userid/ where /userid/ consists of 1 to 16 contiguous
alphanumeric ASCII characters (including the hyphen, dollar sign,
and underscore) identifying the source task. _Example_: ;USERID:ALIBABA
* ;*PASSWORD*:/password/ where /password/ consists of 1 to a
contiguous alphanumeric ASCII characters (including the hyphen,
dollar sign, and underscore) required by the target task to validate
the connection. _Example_: ;PASSWORD:SESAME
* *;CHARGE*:/acctno/ where /acctno/ consists of 1 to 16 contiguous
alphanumeric ASCII characters (including the hyphen, dollar sign,
and underscore) representing the source task's account
identification. _Example_: ;CHARGE:ACCT-13C
* *;DATA*:/userdata/ where /userdata/ consists of 1 to 16 contiguous
alphanumeric ASCII characters (including the hyphen, dollar sign,
and underscore) representing user data. _Example_: ;DATA:THIS-IS-A-TEST
I've since found out that I'm *wrong* about USERID, and that it actually
allows up to 39 characters and have tested this.
What specification has these field definitions and limits? I'd like to
look at it before I go digging into Tops-20 and, of course, fixing the
finger server.
