Attention is currently required from: Arne Schwabe, [email protected].

Selva Nair has posted comments on this change by [email protected]. ( 
https://gerrit.openvpn.net/c/openvpn/+/2148?usp=email )

Change subject: Implement multiline responses for pkcs11-id commands
......................................................................


Patch Set 1: Code-Review-1

(4 comments)

Patchset:

PS1:
Apart from comments below, in management-notes.txt, under OUTPUT_FORMAT no. 
(2), we say 'the last line will be "END"'. Add 'or "ERROR"' to it.


File doc/management-notes.txt:

https://gerrit.openvpn.net/c/openvpn/+/2148/comment/5cc4461f_a8ffdb34?usp=email 
:
PS1, Line 631:      END
Describe the protocol in the both cases separately from examples? Like:

For management client versions < 7:

  pkcs11-id-count

The reply is ">PKCS11ID-COUNT:<count>".

Example:

  pkcs11-id-count
  \>PKCS11ID-COUNT:5

For management client versions >= 7:

  pkcs11-id-count

The reply is a decimal count followed by "END" on a line of its own.

Example:

  pkcs11-id-count
  5
  END


https://gerrit.openvpn.net/c/openvpn/+/2148/comment/c76c252a_87366f38?usp=email 
:
PS1, Line 641: Example for client version < 7:
This section is confusing. Separate client version < 7 and >= 7 cleanly and 
provide protocol description separately from examples?

For management client versions < 7:

  pkcs11-id-get <index>

.. desccribe legacy reply format.

Example:
...

For management client versions >= 7:

  pkcs11-id-get <index>
  pkcs11-id-get <start> <end>
  pkcs11-id-get all

...index/range semantics, record format, END/ERROR termination...

Examples:
...

Also no need to retain the original '<snip>' as that's not how other examples 
are written. ID:'<id>', BLOB:'<blob>' is better.


File src/openvpn/manage.c:

https://gerrit.openvpn.net/c/openvpn/+/2148/comment/049a071a_702e63d8?usp=email 
:
PS1, Line 918:
Two helpers split a small parsing operation, interpret the start argument 
twice, and mix parsing with bounds clamping. A poor abstraction. I don’t see 
sufficient maintenance benefit from this.
Better to leave remote-entry-get unchanged and use similar parsing logic here.

A better range parsing and validation could be a follow up.



--
To view, visit https://gerrit.openvpn.net/c/openvpn/+/2148?usp=email
To unsubscribe, or for help writing mail filters, visit 
https://gerrit.openvpn.net/settings?usp=email

Gerrit-MessageType: comment
Gerrit-Project: openvpn
Gerrit-Branch: master
Gerrit-Change-Id: I09e55085cde6dbc0040e111a42128527d59832b8
Gerrit-Change-Number: 2148
Gerrit-PatchSet: 1
Gerrit-Owner: [email protected]
Gerrit-Reviewer: Arne Schwabe <[email protected]>
Gerrit-Reviewer: Selva Nair <[email protected]>
Gerrit-CC: openvpn-devel <[email protected]>
Gerrit-Attention: [email protected]
Gerrit-Attention: Arne Schwabe <[email protected]>
Gerrit-Comment-Date: Sat, 07 Nov 2026 17:10:52 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to