NTLM S'acaba a Git/libcurl: Els Equips d'Azure DevOps Server Necessiten un Pla de Migració Real

Emiliano Montesdeoca — Mon, 20 Jul 2026 00:00:00 +0000

L’eliminació de NTLM a libcurl és un d’aquells canvis que sembla tècnic però que en realitat és organitzatiu. Si el vostre camí de Git sobre HTTPS a Azure DevOps Server encara depèn de NTLM, el vostre problema no és d’eines, és de deute d’identitat.

Font original: https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/

Microsoft fa bé d’empènyer amb fermesa aquí. NTLM té debilitats criptogràfiques conegudes i no hauria de ser un valor predeterminat empresarial modern. La part perillosa és que molts entorns creuen que estan utilitzant Kerberos quan en realitat estan sobrevivint amb una fallada silenciosa de SPNEGO a NTLM. Aquesta il·lusió desapareix al setembre de 2026.

La meva opinió: no tracteu això com un problema de “versió del client.” Rehabilitar les banderes de NTLM, fixar builds antics de Git o esperar que la fallada romangui disponible és una solució temporal de curta durada amb risc a llarg termini. Si la vostra estratègia de remediació és degradar i retardar, esteu augmentant activament la fragilitat operativa.

Una seqüència de migració pràctica hauria de ser directa i mesurable.

Primer, verifiqueu el comportament d’autenticació actual ara. Executeu comprovacions basades en traces i validació de la cau de tiquets en contextos reals de desenvolupadors i agents de compilació, incloent camins fora de domini i de xarxa remota. Segon, corregiu Kerberos de punta a punta: SPNs, àlies DNS, configuració del balancejador de càrrega, delegació i accessibilitat del controlador de domini. Tercer, identifiqueu els escenaris no units a domini o de grup de treball aviat i dissenyeu un carril SSH on Kerberos no es pugui fer fiable.

També necessiteu claredat de propietat. Els equips de seguretat haurien de definir les línies base de política, però l’enginyeria de plataforma ha de tenir la responsabilitat de la implementació. Això no pot ser una tasca secundària per a administradors de repositori individuals. Requereix canvis coordinats a través d’IIS, AD, la vora de xarxa, els agents de CI i la guia per a estacions de treball de desenvolupadors.

Un risc subtil és l’automatització. Els agents de compilació i els comptes de servei sovint s’executen en contextos on els tiquets Kerberos falten o són invàlids, fins i tot quan els usuaris humans estan bé. Si només proveu fluxos de treball de desenvolupadors interactius, us perdreu els punts de trencament més crítics.

La part positiva és real. Moure’s netament a Kerberos o SSH no només evita la ruptura, sinó que redueix la superfície d’atac i alinea els controls d’identitat amb les expectatives de compliment modernes. Els equips que comencin aquesta transició ara tractaran setembre com un no-esdeveniment. Els equips que esperin estaran depurant fallades d’autenticació sota pressió de llançament.

Això no és un avís per arxivar. És una data límit contra la qual executar.

Revisar pull requests dins de Visual Studio és exactament el tipus de reducció de fricció que m'agrada

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

Aquest article s’ha traduït automàticament. L’original és aquí.

El navegador ha estat robant massa part del flux de treball de code review durant massa temps.

Per això em fa molta il·lusió veure Visual Studio avançar encara més cap a la revisió de pull requests de principi a fi dins de l’IDE.

Aquesta és una d’aquelles funcions que pot no generar grans titulars, però que pot millorar molt el desenvolupament quotidià.

El valor principal és simple: menys canvi de context

Quan el teu bucle de review viu parcialment dins de l’IDE i parcialment al navegador, la fricció s’acumula:

obre el PR en un altre lloc
inspecciona els canvis en una eina
torna a la solució per investigar més a fons
canvia una altra vegada per comentar o aprovar

No és catastròfic. Només és ineficient.

Si Visual Studio et permet obrir, inspeccionar, comentar, aprovar i fer merge des del mateix entorn de treball, això és un guany de productivitat real.

L’opció de “review sense checkout” és especialment bona

Una part que m’agrada especialment és poder revisar sense fer checkout de la branca del PR.

Pot semblar petit, però és perfecte per a:

passades ràpides de review
sol·licituds de feedback interrompudes
mantenir intactes la branca actual i l’estat local

Això és exactament el tipus de flexibilitat que necessiten les bones eines de code review.

La meva opinió

Això no és una funció revolucionària.

És una cosa millor: una funció pràctica.

Per als equips que passen la major part del dia a Visual Studio, un suport més estret per al review de PR significa menys interrupcions del flux de treball i un camí més suau de la inspecció a l’acció.

És una millora que val la pena, al meu parer.

Publicació original: Revisa pull requests sense sortir de Visual Studio

Git | The .NET Blog

NTLM S'acaba a Git/libcurl: Els Equips d'Azure DevOps Server Necessiten un Pla de Migració Real

Revisar pull requests dins de Visual Studio és exactament el tipus de reducció de fricció que m'agrada

El valor principal és simple: menys canvi de context

L’opció de “review sense checkout” és especialment bona

La meva opinió