Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change LDAP - PANIC: runtime error: invalid memory address or nil pointer dereference #16252

Closed
2 of 6 tasks
FLeven opened this issue Jun 25, 2021 · 15 comments · Fixed by #16268 or #16465
Closed
2 of 6 tasks

Change LDAP - PANIC: runtime error: invalid memory address or nil pointer dereference #16252

FLeven opened this issue Jun 25, 2021 · 15 comments · Fixed by #16268 or #16465
Labels
Milestone

Comments

@FLeven
Copy link

FLeven commented Jun 25, 2021

  • Gitea version (or commit ref): v1.14.3 or v1.13.7

  • Git version: 2.32.0

  • Operating system: Windows Server Core 2019

    • Git-go Version
    • gitea-1.14.3-windows-4.0-amd64
    • Docker and / or local
  • Database (use [x]):

    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:

    • Yes (provide example URL)
    • No
  • Log gist (local):

2021/06/25 20:23:10 ...l/manager_windows.go:85:start() [T] Not running a service ... using the debug SVC manager
2021/06/25 20:23:10 ...l/manager_windows.go:101:Execute() [T] Awaiting server start-up
2021/06/25 20:23:10 cmd/web.go:82:runWeb() [I] Starting Gitea on PID: 5508
2021/06/25 20:23:10 ...dules/setting/git.go:101:newGit() [I] Git Version: 2.32.0, Wire Protocol Version 2 Enabled
2021/06/25 20:23:10 cmd/web.go:126:runWeb() [I] Global init
2021/06/25 20:23:10 ...dules/setting/git.go:101:newGit() [I] Git Version: 2.32.0, Wire Protocol Version 2 Enabled
2021/06/25 20:23:11 routers/init.go:134:GlobalInit() [T] AppPath: G:/Gitea/gitea-amd64.exe
2021/06/25 20:23:11 routers/init.go:135:GlobalInit() [T] AppWorkPath: G:/Gitea
2021/06/25 20:23:11 routers/init.go:136:GlobalInit() [T] Custom path: G:/Gitea/custom
2021/06/25 20:23:11 routers/init.go:137:GlobalInit() [T] Log path: G:/data/log
2021/06/25 20:23:11 routers/init.go:49:checkRunMode() [I] Run Mode: Prod
2021/06/25 20:23:12 ...dules/setting/log.go:287:newLogService() [I] Gitea v1.14.3 built with GNU Make 4.1, go1.16.5 : bindata, sqlite, sqlite_unlock_notify
2021/06/25 20:25:46 ...uters/routes/base.go:153:1() [E] PANIC: runtime error: invalid memory address or nil pointer dereference
/usr/local/go/src/runtime/panic.go:212 (0x1003864)
/usr/local/go/src/runtime/signal_windows.go:239 (0x100371e)
/source/models/login_source.go:262 (0x2c7981a)
/source/routers/admin/auths.go:309 (0x2c7982b)
/source/modules/web/route.go:64 (0x2ba1ffb)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/mux.go:436 (0x274ba6a)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/web/route.go:103 (0x2ba26e9)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/web/route.go:103 (0x2ba26e9)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/web/route.go:103 (0x2ba26e9)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/web/route.go:103 (0x2ba26e9)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/middleware/get_head.go:37 (0x2dd3fe1)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/context/context.go:704 (0x276b121)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/routers/routes/base.go:94 (0x2ddb6ac)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/routers/routes/base.go:94 (0x2ddb6ac)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/public/public.go:86 (0x1fd800c)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/public/public.go:86 (0x1fd800c)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/routers/routes/base.go:199 (0x2ddd317)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/gitea.com/go-chi/session/session.go:256 (0x212ed6e)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/mux.go:70 (0x274956a)
/source/vendor/github.com/go-chi/chi/mux.go:311 (0x274fa1b)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/mux.go:436 (0x274ba6a)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/routers/routes/web.go:107 (0x2dde7a4)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/middleware/strip.go:30 (0x2dd4927)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/chi-middleware/proxy/middleware.go:37 (0x2dcfe53)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/routers/routes/web.go:63 (0x2dde2e7)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/mux.go:87 (0x27492f0)
/source/modules/web/route.go:298 (0x2ba151a)
/source/vendor/github.com/gorilla/context/context.go:141 (0x1d980fa)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/usr/local/go/src/net/http/server.go:2887 (0x1388ee9)
/usr/local/go/src/net/http/server.go:1952 (0x138436c)
/usr/local/go/src/runtime/asm_amd64.s:1371 (0x1026640)

Description

When I try to change any authentication source I get a 500 site and the above mentionesd runtime error and it is impossible to change any LDAP settings afterwards.

@zeripath
Copy link
Contributor

zeripath commented Jun 25, 2021

The NPE is coming from looking at the login_source which is defined as a LDAP source but doesn't appear to have a Cfg which is an LDAP source.

There is very likely to be an error earlier that we are missing but it would be also helpful to review the database for this login_source looking at the login_sources with type 2 or 5 in particular looking for those with empty cfg

@FLeven
Copy link
Author

FLeven commented Jun 25, 2021

Another Test on Win10, local SQL Server, local GiTEA same Problem.

I dont think it maters what you enter as authentication source.

DB output

id type name is_actived is_sync_enabled cfg created_unix updated_unix
1 2 test 1 1 ≻慎敭㨢琢獥≴∬潈瑳㨢氢椭獴搮≥∬潐瑲㨢㌶ⰶ匢捥牵瑩偹潲潴潣≬ㄺ∬歓灩敖楲祦㨢牴敵∬楂摮乄㨢∢∬楂摮慐獳潷摲㨢∢∬獕牥慂敳㨢䌢㵎獵牥ⱳ䍄氽椭獴䐬㵃敤Ⱒ唢敳䑲≎∺Ⱒ䄢瑴楲畢整獕牥慮敭㨢∢∬瑁牴扩瑵乥浡≥∺Ⱒ䄢瑴楲畢整畓湲浡≥∺Ⱒ䄢瑴楲畢整慍汩㨢洢楡≬∬瑁牴扩瑵獥湉楂摮㨢慦獬ⱥ䄢瑴楲畢整卓偈扵楬䭣祥㨢∢∬敓牡档慐敧楓敺㨢ⰰ䘢汩整≲∺挨㵮猥∩∬摁業䙮汩整≲∺Ⱒ刢獥牴捩整䙤汩整≲∺Ⱒ䔢慮汢摥㨢牴敵∬汁潬䑷慥瑣癩瑡䅥汬㨢慦獬ⱥ䜢潲灵䕳慮汢摥㨢慦獬ⱥ䜢潲灵乄㨢∢∬片畯䙰汩整≲∺Ⱒ䜢潲灵敍扭牥䥕≄∺Ⱒ唢敳啲䑉㨢∢} 1624653406 1624653426

CFG is not empty and this is a fresh instance.

@FLeven
Copy link
Author

FLeven commented Jun 25, 2021

Going all the way to 1.12.6 and then it works again.

@zeripath
Copy link
Contributor

The cfg entry is supposed to be json - that doesn't look like json...

@zeripath
Copy link
Contributor

This is very odd, looking at the code

/source/routers/admin/auths.go:302:

	source, err := models.GetLoginSourceByID(ctx.ParamsInt64(":authid"))
	if err != nil {
		ctx.ServerError("GetLoginSourceByID", err)
		return
	}
	ctx.Data["Source"] = source
	ctx.Data["HasTLS"] = source.HasTLS()
// HasTLS returns true of this source supports TLS.
func (source *LoginSource) HasTLS() bool {
	return ((source.IsLDAP() || source.IsDLDAP()) &&
		source.LDAP().SecurityProtocol > ldap.SecurityProtocolUnencrypted) || // <- This is where the NPE occurs
		source.IsSMTP()
}

Now models.GetLoginSourceByID(ctx.ParamsInt64(":authid")) cannot return a nil otherwise it would error out.

So the only thing I can see is that the internal *ldap.Source in source.LDAP() is nil because:

// FromDB fills up a LDAPConfig from serialized format.
func (cfg *LDAPConfig) FromDB(bs []byte) error {
	json := jsoniter.ConfigCompatibleWithStandardLibrary
	return json.Unmarshal(bs, &cfg)
}

this fails or returns an error. But I don't understand that.


I can't reproduce this error here on SQLite or Postgres. So I think unless you can see something wrong with the json that is in that cfg, the only solution is going to be compiling in additional logging. Are you able to do that?

@FLeven
Copy link
Author

FLeven commented Jun 25, 2021

No sry,
I pushed the working version 1.12.6 through all other version to find out where it will break, but it didn't, it is even working with the newest version. I checked the DB with every version and the CFG was readable.

Also the other authentication methods are also not working, they don't show a 500 error, but not all settings are saved.

id type name is_actived is_sync_enabled cfg created_unix updated_unix
1 2 test 1 1 ≻慎敭㨢琢獥≴∬潈瑳㨢氢椭獴搮≥∬潐瑲㨢㌶ⰶ匢捥牵瑩偹潲潴潣≬ㄺ∬歓灩敖楲祦㨢牴敵∬楂摮乄㨢∢∬楂摮慐獳潷摲㨢∢∬獕牥慂敳㨢䌢㵎獵牥ⱳ䍄氽椭獴䐬㵃敤Ⱒ唢敳䑲≎∺Ⱒ䄢瑴楲畢整獕牥慮敭㨢∢∬瑁牴扩瑵乥浡≥∺Ⱒ䄢瑴楲畢整畓湲浡≥∺Ⱒ䄢瑴楲畢整慍汩㨢洢楡≬∬瑁牴扩瑵獥湉楂摮㨢牴敵∬瑁牴扩瑵卥䡓畐汢捩敋≹∺Ⱒ匢慥捲偨条卥穩≥〺∬楆瑬牥㨢⠢湣┽⥳Ⱒ䄢浤湩楆瑬牥㨢∢∬敒瑳楲瑣摥楆瑬牥㨢∢∬湅扡敬≤琺畲ⱥ䄢汬睯敄捡楴慶整汁≬昺污敳∬片畯獰湅扡敬≤昺污敳∬片畯䑰≎∺Ⱒ䜢潲灵楆瑬牥㨢∢∬片畯䵰浥敢啲䑉㨢∢∬獕牥䥕≄∺索 1624653406 1624655344
2 2 ldap 1 1 ≻慎敭㨢氢慤≰∬潈瑳㨢氢慤⹰⵬瑩⹳敤Ⱒ倢牯≴㘺㘳∬敓畣楲祴牐瑯捯汯㨢ⰱ匢楫噰牥晩≹琺畲ⱥ䈢湩䑤≎∺乃琽獥ⱴ乃甽敳獲䐬㵃⵬瑩ⱳ䍄搽≥∬楂摮慐獳潷摲㨢␢牴扵ㅢ㌲Ⱒ唢敳䉲獡≥∺乃甽敳獲䐬㵃⵬瑩ⱳ䍄搽≥∬獕牥乄㨢∢∬瑁牴扩瑵啥敳湲浡≥∺Ⱒ䄢瑴楲畢整慎敭㨢∢∬瑁牴扩瑵卥牵慮敭㨢∢∬瑁牴扩瑵䵥楡≬∺慭汩Ⱒ䄢瑴楲畢整䥳䉮湩≤昺污敳∬瑁牴扩瑵卥䡓畐汢捩敋≹∺Ⱒ匢慥捲偨条卥穩≥〺∬楆瑬牥㨢⠢湣┽⥳Ⱒ䄢浤湩楆瑬牥㨢∢∬敒瑳楲瑣摥楆瑬牥㨢∢∬湅扡敬≤琺畲ⱥ䄢汬睯敄捡楴慶整汁≬昺污敳∬片畯獰湅扡敬≤昺污敳∬片畯䑰≎∺Ⱒ䜢潲灵楆瑬牥㨢∢∬片畯䵰浥敢啲䑉㨢∢∬獕牥䥕≄∺索 1624659388 1624659404
3 6 oa 1 0 ≻牐癯摩牥㨢朢瑩慥Ⱒ䌢楬湥䥴≄∺ㄲㄳ㌲‱Ⱒ䌢楬湥却捥敲≴∺㈱ㄳ㌲㌲Ⱒ伢数䥮䍄湯敮瑣畁潴楄捳癯牥啹䱒㨢∢∬畃瑳浯剕䵌灡楰杮㨢≻畁桴剕≌∺瑨灴㩳⼯楧整⹡潣⽭潬楧⽮慯瑵⽨畡桴牯穩≥∬潔敫啮䱒㨢栢瑴獰⼺术瑩慥挮浯氯杯湩漯畡桴愯捣獥彳潴敫≮∬牐景汩啥䱒㨢栢瑴獰⼺术瑩慥挮浯愯楰瘯⼱獵牥Ⱒ䔢慭汩剕≌∺索∬捉湯剕≌∺索 1624659444 1624659491
4 7 auth 1 0 ≻畁潴牃慥整獕牥≳琺畲ⱥ䄢瑵䅯瑣癩瑡啥敳獲㨢牴敵∬瑓楲䑰浯楡乮浡獥㨢牴敵∬敓慰慲潴割灥慬散敭瑮㨢ⴢⰢ䐢晥畡瑬慌杮慵敧㨢∢} 1624659517 1624659560

@zeripath
Copy link
Contributor

Those cfg fields are being returned as bytes in whatever way you're pasting them in here. Likely this is because of our schema but there should be someway of casting them to strings for us to check if they're actually reasonable JSON.

@FLeven
Copy link
Author

FLeven commented Jun 26, 2021

This is exactly how the config looks like in MS Sql Studio, just copy/pasted it here,

To be clear, the initial setup of any authentication source works and it look fine in the DB. LDAP for example works, login ok.
Only if you try to change anything and save the changes, then it gets scrambled in the DB and LDAP authentication is broken, no login possible. I have to add a new source and change every existing user to the new source, delete the old one and it is working again.

Workaround:
Install 1.12.6 and update to 1.13.7 (maybe you can skip this step), then update to 1.14.3 and everything works as expected.

@zeripath
Copy link
Contributor

This is exactly how the config looks like in MS Sql Studio, just copy/pasted it here,

Before or after attempting to edit it? Would you be able to cast it as a string or even just give me the bytes themselves?

To be clear, the initial setup of any authentication source works and it look fine in the DB. LDAP for example works, login ok.
Only if you try to change anything and save the changes, then it gets scrambled in the DB and LDAP authentication is broken, no login possible. I have to add a new source and change every existing user to the new source, delete the old one and it is working again.

This suggests an issue with collations or encodings but I don't understand it.

Workaround:
Install 1.12.6 and update to 1.13.7 (maybe you can skip this step), then update to 1.14.3 and everything works as expected.

This isn't really a viable solution for most people - and it doesn't explain why 1.12.6 works when 1.14.3 doesn't.

@FLeven
Copy link
Author

FLeven commented Jun 26, 2021

Plain export of the table:

working.txt
notworking.txt

I also setup the DB with a different collation (closer to UTF8mb4), but it changed nothing. Default language of my server/DB is german.

@zeripath
Copy link
Contributor

zeripath commented Jun 26, 2021

Yep. OK looking at those bytes - they have been changed in to UTF16 with incorrectly prefixed with the UTF16 BOM.

@6543 6543 added this to the 1.15.0 milestone Jun 26, 2021
@6543 6543 added the type/bug label Jun 26, 2021
@zeripath
Copy link
Contributor

and I've managed to replicate the issue too.

@zeripath
Copy link
Contributor

OK it's a bug with xorm.

@zeripath
Copy link
Contributor

https://gitea.com/xorm/xorm/pulls/1957 is the bug fix PR.

The issue is that there is a fundamental mismatch with how Blob types and non-Blob types are handled for converts like this in Select, Insert and Update - and MSSQL unfortunately requires the special cast.

zeripath added a commit to zeripath/gitea that referenced this issue Jun 27, 2021
zeripath added a commit to zeripath/gitea that referenced this issue Jun 27, 2021
Unfortunately due a bug in xorm (see https://gitea.com/xorm/xorm/pulls/1957) updating
loginsources on MSSQL causes them to become corrupted. (go-gitea#16252)

Whilst waiting for the referenced PR to be merged and to handle the corrupted
loginsources correctly we need to add a wrapper to the `FromDB()` methods to look
for and ignore the misplaced BOMs that have been added.

Fix go-gitea#16252

Signed-off-by: Andrew Thornton <[email protected]>
zeripath added a commit to zeripath/gitea that referenced this issue Jun 27, 2021
techknowlogick pushed a commit that referenced this issue Jun 27, 2021
* Handle misencoding of login_source cfg in mssql

Unfortunately due a bug in xorm (see https://gitea.com/xorm/xorm/pulls/1957) updating
loginsources on MSSQL causes them to become corrupted. (#16252)

Whilst waiting for the referenced PR to be merged and to handle the corrupted
loginsources correctly we need to add a wrapper to the `FromDB()` methods to look
for and ignore the misplaced BOMs that have been added.

Fix #16252

Signed-off-by: Andrew Thornton <[email protected]>

* Update models/login_source.go
zeripath added a commit to zeripath/gitea that referenced this issue Jun 27, 2021
Backport go-gitea#16268

Unfortunately due a bug in xorm (see https://gitea.com/xorm/xorm/pulls/1957) updating
loginsources on MSSQL causes them to become corrupted. (go-gitea#16252)

Whilst waiting for the referenced PR to be merged and to handle the corrupted
loginsources correctly we need to add a wrapper to the `FromDB()` methods to look
for and ignore the misplaced BOMs that have been added.

Fix go-gitea#16252

Signed-off-by: Andrew Thornton <[email protected]>
zeripath added a commit that referenced this issue Jun 27, 2021
Backport #16268

Unfortunately due a bug in xorm (see https://gitea.com/xorm/xorm/pulls/1957) updating
loginsources on MSSQL causes them to become corrupted. (#16252)

Whilst waiting for the referenced PR to be merged and to handle the corrupted
loginsources correctly we need to add a wrapper to the `FromDB()` methods to look
for and ignore the misplaced BOMs that have been added.

Fix #16252

Signed-off-by: Andrew Thornton <[email protected]>
@zeripath
Copy link
Contributor

There's probably another similar issue regarding repo units which are likely to suffer the same problem

zeripath added a commit to zeripath/gitea that referenced this issue Jul 16, 2021
One of the reasons why go-gitea#16447 was needed and why go-gitea#16268 was needed in
the first place was because it appears that editing ldap configuration
doesn't get tested.

This PR therefore adds a basic test that will run the edit pipeline.

In doing so it's now clear that go-gitea#16447 and go-gitea#16268 aren't actually
solving go-gitea#16252. It turns out that what actually happens is that is that
the bytes are actually double encoded.

This PR now changes the json unmarshal wrapper to handle this double
encode.

Fix go-gitea#16252

Signed-off-by: Andrew Thornton <[email protected]>
lafriks pushed a commit that referenced this issue Jul 20, 2021
One of the reasons why #16447 was needed and why #16268 was needed in
the first place was because it appears that editing ldap configuration
doesn't get tested.

This PR therefore adds a basic test that will run the edit pipeline.

In doing so it's now clear that #16447 and #16268 aren't actually
solving #16252. It turns out that what actually happens is that is that
the bytes are actually double encoded.

This PR now changes the json unmarshal wrapper to handle this double
encode.

Fix #16252

Signed-off-by: Andrew Thornton <[email protected]>

Co-authored-by: 6543 <[email protected]>
zeripath added a commit to zeripath/gitea that referenced this issue Jul 20, 2021
…#16465)

Backport go-gitea#16465

One of the reasons why go-gitea#16447 was needed and why go-gitea#16268 was needed in
the first place was because it appears that editing ldap configuration
doesn't get tested.

This PR therefore adds a basic test that will run the edit pipeline.

In doing so it's now clear that go-gitea#16447 and go-gitea#16268 aren't actually
solving go-gitea#16252. It turns out that what actually happens is that is that
the bytes are actually double encoded.

This PR now changes the json unmarshal wrapper to handle this double
encode.

Fix go-gitea#16252

Signed-off-by: Andrew Thornton <[email protected]>
zeripath added a commit to zeripath/gitea that referenced this issue Jul 20, 2021
…#16465)

Backport go-gitea#16465

One of the reasons why go-gitea#16447 was needed and why go-gitea#16268 was needed in
the first place was because it appears that editing ldap configuration
doesn't get tested.

This PR therefore adds a basic test that will run the edit pipeline.

In doing so it's now clear that go-gitea#16447 and go-gitea#16268 aren't actually
solving go-gitea#16252. It turns out that what actually happens is that is that
the bytes are actually double encoded.

This PR now changes the json unmarshal wrapper to handle this double
encode.

Fix go-gitea#16252

Signed-off-by: Andrew Thornton <[email protected]>
lafriks pushed a commit that referenced this issue Jul 22, 2021
Backport #16465

One of the reasons why #16447 was needed and why #16268 was needed in
the first place was because it appears that editing ldap configuration
doesn't get tested.

This PR therefore adds a basic test that will run the edit pipeline.

In doing so it's now clear that #16447 and #16268 aren't actually
solving #16252. It turns out that what actually happens is that is that
the bytes are actually double encoded.

This PR now changes the json unmarshal wrapper to handle this double
encode.

Fix #16252

Signed-off-by: Andrew Thornton <[email protected]>

Co-authored-by: 6543 <[email protected]>
lafriks pushed a commit that referenced this issue Jul 22, 2021
Backport #16465

One of the reasons why #16447 was needed and why #16268 was needed in
the first place was because it appears that editing ldap configuration
doesn't get tested.

This PR therefore adds a basic test that will run the edit pipeline.

In doing so it's now clear that #16447 and #16268 aren't actually
solving #16252. It turns out that what actually happens is that is that
the bytes are actually double encoded.

This PR now changes the json unmarshal wrapper to handle this double
encode.

Fix #16252

Signed-off-by: Andrew Thornton <[email protected]>

Co-authored-by: 6543 <[email protected]>
zeripath added a commit to zeripath/gitea that referenced this issue Aug 4, 2021
[1.14.6](https://github.com/go-gitea/gitea/releases/tag/v1.14.6) - 2021-08-04

* SECURITY
  * Bump github.com/markbates/goth from v1.67.1 to v1.68.0 (go-gitea#16538) (go-gitea#16540)
  * Switch to maintained JWT lib (go-gitea#16532) (go-gitea#16535)
  * Upgrade to latest version of golang-jwt (as forked for 1.14) (go-gitea#16590) (go-gitea#16607)
* BUGFIXES
  * Add basic edit ldap auth test & actually fix go-gitea#16252 (go-gitea#16465) (go-gitea#16495)
  * Make cancel from CatFileBatch and CatFileBatchCheck wait for the command to end (go-gitea#16479) (go-gitea#16481)

Signed-off-by: Andrew Thornton <[email protected]>
zeripath added a commit that referenced this issue Aug 5, 2021
## [1.14.6](https://github.com/go-gitea/gitea/releases/tag/v1.14.6) - 2021-08-04

* SECURITY
  * Bump github.com/markbates/goth from v1.67.1 to v1.68.0 (#16538) (#16540)
  * Switch to maintained JWT lib (#16532) (#16535)
  * Upgrade to latest version of golang-jwt (as forked for 1.14) (#16590) (#16607)
* BUGFIXES
  * Add basic edit ldap auth test & actually fix #16252 (#16465) (#16495)
  * Make cancel from CatFileBatch and CatFileBatchCheck wait for the command to end (#16479) (#16481)

Signed-off-by: Andrew Thornton <[email protected]>
AbdulrhmnGhanem pushed a commit to kitspace/gitea that referenced this issue Aug 10, 2021
* Handle misencoding of login_source cfg in mssql

Unfortunately due a bug in xorm (see https://gitea.com/xorm/xorm/pulls/1957) updating
loginsources on MSSQL causes them to become corrupted. (go-gitea#16252)

Whilst waiting for the referenced PR to be merged and to handle the corrupted
loginsources correctly we need to add a wrapper to the `FromDB()` methods to look
for and ignore the misplaced BOMs that have been added.

Fix go-gitea#16252

Signed-off-by: Andrew Thornton <[email protected]>

* Update models/login_source.go
AbdulrhmnGhanem pushed a commit to kitspace/gitea that referenced this issue Aug 10, 2021
…#16465)

One of the reasons why go-gitea#16447 was needed and why go-gitea#16268 was needed in
the first place was because it appears that editing ldap configuration
doesn't get tested.

This PR therefore adds a basic test that will run the edit pipeline.

In doing so it's now clear that go-gitea#16447 and go-gitea#16268 aren't actually
solving go-gitea#16252. It turns out that what actually happens is that is that
the bytes are actually double encoded.

This PR now changes the json unmarshal wrapper to handle this double
encode.

Fix go-gitea#16252

Signed-off-by: Andrew Thornton <[email protected]>

Co-authored-by: 6543 <[email protected]>
@go-gitea go-gitea locked and limited conversation to collaborators Oct 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
3 participants