Bug #2557
Incorrect handling of unknown transform types in proposals
Description
Hi,
According to RFC7296, Section 3.3.6 we have:
If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. Similarly, if the responder receives a transform that it does not understand, or one that contains a Transform Attribute it does not understand, it MUST consider this transform unacceptable; other transforms with the same Transform Type are processed as usual. This allows new Transform Types and Transform Attributes to be defined in the future.
However, when StrongSwan receives a proposal containing an unknown transform-type, it ignores the transform type, but it does not consider the proposal to be unacceptable. In other words, StrongSwan does not consider the unknown transform-type as a part of the proposal. Following the paragraph above, I believe this behaviour is non-conformance to RFC7296.
Consider the following scenario wherebymoon
(192.168.56.103) is running a version of StrongSwan 5.6.2, and sun
(192.168.56.102) sends an IKE_SA_INIT request containing a transform type that moon
does not understand. Assume that moon
is configured to support the following proposals on IKE:
- PROPOSAL 1:
aes256gcm16-sha256-ecp384
- PROPOSAL 2:
aes256gcm16-sha256-ecp521
sun
sends the following IKE proposals, where the first proposal contains an unknown transform type:
- PROPOSAL 1:
aes256gcm16-sha256-ecp384-unknown_transform_type_247_id_2052
- PROPOSAL 2:
aes256gcm16-sha256-ecp521
On receipts of this IKE_SA_INIT request form sun
, the peer moon
accepts the first proposal, which is incorrect. It should respond with INVALID_KE_PAYLOAD notification suggesting to use ECP_521.
I believe the patch in https://github.com/post-quantum/strongswan/commit/77bd7994bd69d3c9f47f3af9bc80dbbdc090b841 should fix this behaviour in accordance to RFC7296.
I would be grateful to get your feedbacks and let me know if you have any questions.
Best regards,
CJ
The content of /etc/ipsec.conf
of moon
is shown below:
# ipsec.conf - strongSwan IPsec configuration file config setup charondebug="ike 4, lib 4, cfg 4, chd 4, net 4, enc 1" conn mytunnel left=192.168.56.103 right=192.168.56.102 authby=secret rekey=yes fragmentation=yes keyexchange=ikev2 ike="aes256gcm16-sha256-ecp384,aes256gcm16-sha256-ecp521!" esp="aes256gcm16-sha256-ecp521,aes256gcm16-sha256-ecp384!" auto=add
I use the following bash
script, which is also attached, to send an IKE_SA_INIT request with unknown transform type:
#!/bin/bash
if [ $# -lt 4 ]; then
echo
echo "$0 [Transform type] [Transform ID] [Target IPv4] [Target Port]"
echo
exit -1
fi
echo "29dd53c20637db650000000000000000212022080000000000000168220000540200002c010100040300000c01000014800e01000300000802000005030000080400001400000008TT00IIII00000024020100030300000c01000014800e010003000008020000050000000804000015280000680014000037ac957a1e5d046a6b5f43b8bfe952c0626fb12026389a37f152deef97a2707cec9ef31dacb339e64082f439cf88d140f4e0ee23f479b2b74e5f0c82d1416bafca94c1ce41aa65e72b5dc05f225ab8d75b5e75663e411e080e5182aac89acb2229000024dd77090fcfc869fe6c768d50123fc5c8c72f1c1a4548778b905f3aa53dd8a1e82900001c000040046afeccb56b083e09011e051204d5cdb5f1349aac2900001c0000400581643a0fda73440443c0e5c273a5a47403fc2472290000080000402e290000100000402f00020003000400052b0000080000401600000014882fe56d6fd20dbc2251613b2ebe5beb" | sed -e "s/TT/`printf %02x $1 | cut -c 1-2`/" -e "s/IIII/`printf %04x $2 | cut -c 1-4 | xxd -r -p | od -t x2 -An | tr -dc '[:alnum:]'`/" | xxd -r -p | netcat -4 -u $3 $4
StrongSwan 5.6.2 is running on the peer moon
with IP address 192.168.56.103 at UDP port 500. In order to mimic sun
in sending an unknown transform of type 247 and transform ID of 2052, the following script is executed from the peer sun
:
./ikev2_send_unknown_transform.sh 247 2052 192.168.56.103 500 | hexdump -C
and the
tcpdump
captured packets are shown below: 16:22:27.009757 IP (tos 0x0, ttl 64, id 40491, offset 0, flags [DF], proto UDP (17), length 388) 192.168.56.102.48592 > 192.168.56.103.isakmp: [udp sum ok] isakmp 2.0 msgid 00000000 cookie 29dd53c20637db65->0000000000000000: parent_sa ikev2_init[I]: (sa: len=80 (p: #1 protoid=isakmp transform=4 len=44 (t: #1 type=encr id=#20 (type=keylen value=0100)) (t: #2 type=prf id=#5 ) (t: #3 type=dh id=#20 ) (t: #4 type=#247 id=2052 )) (p: #2 protoid=isakmp transform=3 len=36 (t: #1 type=encr id=#20 (type=keylen value=0100)) (t: #2 type=prf id=#5 ) (t: #3 type=dh id=#21 ))) (v2ke: len=96 group=#20 37ac957a1e5d046a6b5f43b8bfe952c0626fb12026389a37f152deef97a2707cec9ef31dacb339e64082f439cf88d140f4e0ee23f479b2b74e5f0c82d1416bafca94c1ce41aa65e72b5dc05f225ab8d75b5e75663e411e080e5182aac89acb22) (nonce: len=32 nonce=(dd77090fcfc869fe6c768d50123fc5c8c72f1c1a4548778b905f3aa53dd8a1e8) ) (n: prot_id=#0 type=16388(nat_detection_source_ip)) (n: prot_id=#0 type=16389(nat_detection_destination_ip)) (n: prot_id=#0 type=16430(status)) (n: prot_id=#0 type=16431(status)) (n: prot_id=#0 type=16406(status)) (v2vid: len=16 vid=./.mo..."Qa;..[. 882fe56d6fd20dbc2251613b2ebe5beb) 16:22:27.085526 IP (tos 0x0, ttl 64, id 65029, offset 0, flags [DF], proto UDP (17), length 344) 192.168.56.103.isakmp > 192.168.56.102.48592: [bad udp cksum 0xf373 -> 0x3bef!] isakmp 2.0 msgid 00000000 cookie 29dd53c20637db65->d90489c1dc5da833: parent_sa ikev2_init[R]: (sa: len=36 (p: #1 protoid=isakmp transform=3 len=36 (t: #1 type=encr id=#20 (type=keylen value=0100)) (t: #2 type=prf id=#5 ) (t: #3 type=dh id=#20 ))) (v2ke: len=96 group=#20 3a759dd205700348ce1aef3390492415d44c226ad3d60bdbf786c1a042d4d6248ac8a4b47d12e328e6f6da29a3947f005a6d0446e22c711e87a4a22ab855ffff5beff6021bfbb17f6e3885bfd50fac31ea9445a939eccb4b49510f3de10b62a6) (nonce: len=32 nonce=(eda32107ca47e182341d6246976ad0ced9d31dd73aa68d89e7a4e589cbfb2f16) ) (n: prot_id=#0 type=16388(nat_detection_source_ip)) (n: prot_id=#0 type=16389(nat_detection_destination_ip)) (n: prot_id=#0 type=16430(status)) (n: prot_id=#0 type=16431(status)) (n: prot_id=#0 type=16404(status)) (v2vid: len=16 vid=./.mo..."Qa;..[. 882fe56d6fd20dbc2251613b2ebe5beb)
The charon
log output of what sun
receives and responds with is shown below:
Feb 22 16:22:27 strongswan charon: 03[NET] received packet => 360 bytes @ 0x7faed788a3a0 Feb 22 16:22:27 strongswan charon: 03[NET] 0: 29 DD 53 C2 06 37 DB 65 00 00 00 00 00 00 00 00 ).S..7.e........ Feb 22 16:22:27 strongswan charon: 03[NET] 16: 21 20 22 08 00 00 00 00 00 00 01 68 22 00 00 54 ! "........h"..T Feb 22 16:22:27 strongswan charon: 03[NET] 32: 02 00 00 2C 01 01 00 04 03 00 00 0C 01 00 00 14 ...,............ Feb 22 16:22:27 strongswan charon: 03[NET] 48: 80 0E 01 00 03 00 00 08 02 00 00 05 03 00 00 08 ................ Feb 22 16:22:27 strongswan charon: 03[NET] 64: 04 00 00 14 00 00 00 08 F7 00 04 08 00 00 00 24 ...............$ Feb 22 16:22:27 strongswan charon: 03[NET] 80: 02 01 00 03 03 00 00 0C 01 00 00 14 80 0E 01 00 ................ Feb 22 16:22:27 strongswan charon: 03[NET] 96: 03 00 00 08 02 00 00 05 00 00 00 08 04 00 00 15 ................ Feb 22 16:22:27 strongswan charon: 03[NET] 112: 28 00 00 68 00 14 00 00 37 AC 95 7A 1E 5D 04 6A (..h....7..z.].j Feb 22 16:22:27 strongswan charon: 03[NET] 128: 6B 5F 43 B8 BF E9 52 C0 62 6F B1 20 26 38 9A 37 k_C...R.bo. &8.7 Feb 22 16:22:27 strongswan charon: 03[NET] 144: F1 52 DE EF 97 A2 70 7C EC 9E F3 1D AC B3 39 E6 .R....p|......9. Feb 22 16:22:27 strongswan charon: 03[NET] 160: 40 82 F4 39 CF 88 D1 40 F4 E0 EE 23 F4 79 B2 B7 @..9...@...#.y.. Feb 22 16:22:27 strongswan charon: 03[NET] 176: 4E 5F 0C 82 D1 41 6B AF CA 94 C1 CE 41 AA 65 E7 N_...Ak.....A.e. Feb 22 16:22:27 strongswan charon: 03[NET] 192: 2B 5D C0 5F 22 5A B8 D7 5B 5E 75 66 3E 41 1E 08 +]._"Z..[^uf>A.. Feb 22 16:22:27 strongswan charon: 03[NET] 208: 0E 51 82 AA C8 9A CB 22 29 00 00 24 DD 77 09 0F .Q.....")..$.w.. Feb 22 16:22:27 strongswan charon: 03[NET] 224: CF C8 69 FE 6C 76 8D 50 12 3F C5 C8 C7 2F 1C 1A ..i.lv.P.?.../.. Feb 22 16:22:27 strongswan charon: 03[NET] 240: 45 48 77 8B 90 5F 3A A5 3D D8 A1 E8 29 00 00 1C EHw.._:.=...)... Feb 22 16:22:27 strongswan charon: 03[NET] 256: 00 00 40 04 6A FE CC B5 6B 08 3E 09 01 1E 05 12 ..@.j...k.>..... Feb 22 16:22:27 strongswan charon: 03[NET] 272: 04 D5 CD B5 F1 34 9A AC 29 00 00 1C 00 00 40 05 .....4..).....@. Feb 22 16:22:27 strongswan charon: 03[NET] 288: 81 64 3A 0F DA 73 44 04 43 C0 E5 C2 73 A5 A4 74 .d:..sD.C...s..t Feb 22 16:22:27 strongswan charon: 03[NET] 304: 03 FC 24 72 29 00 00 08 00 00 40 2E 29 00 00 10 ..$r).....@.)... Feb 22 16:22:27 strongswan charon: 03[NET] 320: 00 00 40 2F 00 02 00 03 00 04 00 05 2B 00 00 08 ..@/........+... Feb 22 16:22:27 strongswan charon: 03[NET] 336: 00 00 40 16 00 00 00 14 88 2F E5 6D 6F D2 0D BC ..@....../.mo... Feb 22 16:22:27 strongswan charon: 03[NET] 352: 22 51 61 3B 2E BE 5B EB "Qa;..[. Feb 22 16:22:27 strongswan charon: 03[NET] received packet: from 192.168.56.102[48592] to 192.168.56.103[500] Feb 22 16:22:27 strongswan charon: 03[NET] waiting for data on sockets Feb 22 16:22:27 strongswan charon: 08[NET] received packet: from 192.168.56.102[48592] to 192.168.56.103[500] (360 bytes) Feb 22 16:22:27 strongswan charon: 08[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) V ] Feb 22 16:22:27 strongswan charon: 08[CFG] looking for an ike config for 192.168.56.103...192.168.56.102 Feb 22 16:22:27 strongswan charon: 08[CFG] ike config match: 3100 (192.168.56.103 192.168.56.102 IKEv2) Feb 22 16:22:27 strongswan charon: 08[CFG] candidate: 192.168.56.103...192.168.56.102, prio 3100 Feb 22 16:22:27 strongswan charon: 08[CFG] found matching ike config: 192.168.56.103...192.168.56.102 with prio 3100 Feb 22 16:22:27 strongswan charon: 08[IKE] received strongSwan vendor ID Feb 22 16:22:27 strongswan charon: 08[IKE] 192.168.56.102 is initiating an IKE_SA Feb 22 16:22:27 strongswan charon: 08[IKE] IKE_SA (unnamed)[1] state change: CREATED => CONNECTING Feb 22 16:22:27 strongswan charon: 08[CFG] selecting proposal: Feb 22 16:22:27 strongswan charon: 08[CFG] proposal matches Feb 22 16:22:27 strongswan charon: 08[CFG] received proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_384, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521 Feb 22 16:22:27 strongswan charon: 08[CFG] configured proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_384, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521 Feb 22 16:22:27 strongswan charon: 08[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_384 Feb 22 16:22:27 strongswan charon: 08[CFG] received supported signature hash algorithms: sha256 sha384 sha512 identity Feb 22 16:22:27 strongswan charon: 08[IKE] natd_chunk => 22 bytes @ 0x7faeb800b150 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 29 DD 53 C2 06 37 DB 65 00 00 00 00 00 00 00 00 ).S..7.e........ Feb 22 16:22:27 strongswan charon: 08[IKE] 16: C0 A8 38 67 01 F4 ..8g.. Feb 22 16:22:27 strongswan charon: 08[IKE] natd_hash => 20 bytes @ 0x7faeb800a3f0 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 6A FE CC B5 6B 08 3E 09 01 1E 05 12 04 D5 CD B5 j...k.>......... Feb 22 16:22:27 strongswan charon: 08[IKE] 16: F1 34 9A AC .4.. Feb 22 16:22:27 strongswan charon: 08[IKE] natd_chunk => 22 bytes @ 0x7faeb800b150 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 29 DD 53 C2 06 37 DB 65 00 00 00 00 00 00 00 00 ).S..7.e........ Feb 22 16:22:27 strongswan charon: 08[IKE] 16: C0 A8 38 66 BD D0 ..8f.. Feb 22 16:22:27 strongswan charon: 08[IKE] natd_hash => 20 bytes @ 0x7faeb800a3b0 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 5C A3 E2 CE 54 4D F1 A6 0A 83 D4 6D C6 32 4E 27 \...TM.....m.2N' Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 87 B1 64 27 ..d' Feb 22 16:22:27 strongswan charon: 08[IKE] precalculated src_hash => 20 bytes @ 0x7faeb800a3b0 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 5C A3 E2 CE 54 4D F1 A6 0A 83 D4 6D C6 32 4E 27 \...TM.....m.2N' Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 87 B1 64 27 ..d' Feb 22 16:22:27 strongswan charon: 08[IKE] precalculated dst_hash => 20 bytes @ 0x7faeb800a3f0 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 6A FE CC B5 6B 08 3E 09 01 1E 05 12 04 D5 CD B5 j...k.>......... Feb 22 16:22:27 strongswan charon: 08[IKE] 16: F1 34 9A AC .4.. Feb 22 16:22:27 strongswan charon: 08[IKE] received src_hash => 20 bytes @ 0x7faeb8005440 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 6A FE CC B5 6B 08 3E 09 01 1E 05 12 04 D5 CD B5 j...k.>......... Feb 22 16:22:27 strongswan charon: 08[IKE] 16: F1 34 9A AC .4.. Feb 22 16:22:27 strongswan charon: 08[IKE] received dst_hash => 20 bytes @ 0x7faeb80060d0 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 81 64 3A 0F DA 73 44 04 43 C0 E5 C2 73 A5 A4 74 .d:..sD.C...s..t Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 03 FC 24 72 ..$r Feb 22 16:22:27 strongswan charon: 08[IKE] local host is behind NAT, sending keep alives Feb 22 16:22:27 strongswan charon: 08[IKE] remote host is behind NAT Feb 22 16:22:27 strongswan charon: 08[IKE] sending strongSwan vendor ID Feb 22 16:22:27 strongswan charon: 08[IKE] shared Diffie Hellman secret => 48 bytes @ 0x7faeb800c340 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 8E 7D 2A E0 DB 71 94 54 8E 91 69 46 AD 72 0C EF .}*..q.T..iF.r.. Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 38 27 1E 28 85 62 07 51 18 D3 1E A0 8C 9A BD 24 8'.(.b.Q.......$ Feb 22 16:22:27 strongswan charon: 08[IKE] 32: E6 58 90 2C FA FC 94 67 41 C5 46 26 E7 D6 B4 B6 .X.,...gA.F&.... Feb 22 16:22:27 strongswan charon: 08[IKE] SKEYSEED => 32 bytes @ 0x7faeb8005480 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 4A D0 64 B1 93 C8 8F 1F 2E 85 B5 E4 34 38 6F 47 J.d.........48oG Feb 22 16:22:27 strongswan charon: 08[IKE] 16: EB 0A 93 96 6B 29 7A C7 03 70 70 E3 45 A8 B4 78 ....k)z..pp.E..x Feb 22 16:22:27 strongswan charon: 08[IKE] Sk_d secret => 32 bytes @ 0x7faeb800ad20 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 93 28 6C 4C 45 93 75 45 11 6D A1 EA 12 05 70 A7 .(lLE.uE.m....p. Feb 22 16:22:27 strongswan charon: 08[IKE] 16: F2 4A FE 81 2F 8D 58 89 B6 FF FE 72 72 E9 6A 22 .J../.X....rr.j" Feb 22 16:22:27 strongswan charon: 08[IKE] Sk_ei secret => 36 bytes @ 0x7faeb800d440 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: B1 35 BB 4F 6D 29 45 0C 8D 57 19 D4 81 11 EC 05 .5.Om)E..W...... Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 4C 40 EC E6 41 F8 08 9A CE 80 60 DA F3 2A A8 9E L@..A.....`..*.. Feb 22 16:22:27 strongswan charon: 08[IKE] 32: 4B CD 96 DF K... Feb 22 16:22:27 strongswan charon: 08[IKE] Sk_er secret => 36 bytes @ 0x7faeb800c340 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 06 48 51 18 C1 05 FD 56 40 F2 6F 99 FB B6 B7 61 .HQ....V@.o....a Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 24 76 5F F9 2A F8 68 8F DC 6D F9 92 64 2D F4 E6 $v_.*.h..m..d-.. Feb 22 16:22:27 strongswan charon: 08[IKE] 32: 1F 62 A6 31 .b.1 Feb 22 16:22:27 strongswan charon: 08[IKE] Sk_pi secret => 32 bytes @ 0x7faeb800d440 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: FB 10 A4 3C 32 7E FD 5B F2 96 E6 DE 6C D9 06 97 ...<2~.[....l... Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 80 C3 7C A9 D9 7E 79 AE F4 2A 96 EA A1 64 E1 EA ..|..~y..*...d.. Feb 22 16:22:27 strongswan charon: 08[IKE] Sk_pr secret => 32 bytes @ 0x7faeb800c340 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 27 07 C3 75 CD 82 24 0A 8E EB DD 97 56 55 09 D0 '..u..$.....VU.. Feb 22 16:22:27 strongswan charon: 08[IKE] 16: F0 69 A5 7C D2 34 CA 7B F9 AF 7B 65 FF C6 3E 8D .i.|.4.{..{e..>. Feb 22 16:22:27 strongswan charon: 08[CFG] sending supported signature hash algorithms: sha256 sha384 sha512 identity Feb 22 16:22:27 strongswan charon: 08[IKE] natd_chunk => 22 bytes @ 0x7faeb8009270 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 29 DD 53 C2 06 37 DB 65 D9 04 89 C1 DC 5D A8 33 ).S..7.e.....].3 Feb 22 16:22:27 strongswan charon: 08[IKE] 16: C0 A8 38 67 01 F4 ..8g.. Feb 22 16:22:27 strongswan charon: 08[IKE] natd_hash => 20 bytes @ 0x7faeb8009370 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 2C 50 98 79 A7 8E 7D D1 E1 3C 9E CB A0 13 9F 20 ,P.y..}..<..... Feb 22 16:22:27 strongswan charon: 08[IKE] 16: B5 AB CF D2 .... Feb 22 16:22:27 strongswan charon: 08[IKE] natd_chunk => 22 bytes @ 0x7faeb800fec0 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 29 DD 53 C2 06 37 DB 65 D9 04 89 C1 DC 5D A8 33 ).S..7.e.....].3 Feb 22 16:22:27 strongswan charon: 08[IKE] 16: C0 A8 38 66 BD D0 ..8f.. Feb 22 16:22:27 strongswan charon: 08[IKE] natd_hash => 20 bytes @ 0x7faeb8009370 Feb 22 16:22:27 strongswan charon: 08[IKE] 0: E3 6B D4 DE 63 F9 D7 44 CE 29 BE FC 24 AF 59 71 .k..c..D.)..$.Yq Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 53 56 4C 83 SVL. Feb 22 16:22:27 strongswan charon: 08[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) V ] Feb 22 16:22:27 strongswan charon: 08[NET] sending packet: from 192.168.56.103[500] to 192.168.56.102[48592] (316 bytes) Feb 22 16:22:27 strongswan charon: 05[NET] sending packet: from 192.168.56.103[500] to 192.168.56.102[48592]
Associated revisions
History
#1 Updated by Tobias Brunner over 4 years ago
- Status changed from New to Feedback
- Target version set to 5.6.3
Thanks for the report. I agree that the current behavior is not fully compliant with the RFC.
I believe the patch in https://github.com/post-quantum/strongswan/commit/77bd7994bd69d3c9f47f3af9bc80dbbdc090b841 should fix this behaviour in accordance to RFC7296.
I don't think we have to be so restrictive. We just have to make sure to compare all the transform types contained in both proposals. This way we don't have to explicitly change anything if new transform types are added. I pushed patches to this end to the 2557-unknown-transform-types branch. Let me know if these work for you.
#2 Updated by CJ Tjhai over 4 years ago
Hi Tobias,
Many thanks for the patch. Yes, they work for us.
Cheers,
CJ
#3 Updated by Tobias Brunner over 4 years ago
- Subject changed from Incorrect handling of unknown transform type to Incorrect handling of unknown transform types in proposals
- Status changed from Feedback to Closed
- Assignee set to Tobias Brunner
- Resolution set to Fixed
#4 Updated by Tobias Brunner over 4 years ago
Thanks for testing. Merged to master.
Merge branch 'unknown-transform-types'
This changes how unknown transform types are handled in proposals. In
particular we make sure not to accept a proposal if it contains unknown
transform types (they were just ignored previously, which could have
resulted in an invalid selected proposal).
Fixes #2557.