Activities of "JonSteer73"

• ABP Framework version: v8.3.2
• UI Type: Blazor Server
• Database System: EF Core (SQL Server.)
• Tiered (for MVC) or Auth Server Separated (for Angular): no

Hi there. We've run a SAST tool (GitHub advanced security for DevOps) on our Blazor server project and it has noted high severity vulnerabilities in the following packages, which are bundled as part of the ABP libraries:

• System.Text.Json https://github.com/advisories/GHSA-8g4q-xg66-9fp4
• Microsoft.Extensions.Caching.Memory https://github.com/advisories/GHSA-qj66-m88j-hmgj
• SixLabors.ImageSharp https://github.com/advisories/GHSA-63p8-c4ww-9cg7

Are these libraries due to be updated as part of the v9 release? If not, would it be possible to get them patched as part of the next upgrade please?

Thanks! :)

• ABP Framework version: v8.0.1
• UI Type: Blazor Server
• Database System: EF Core (SQL Server)
• Tiered: no
• Exception message and full stack trace: n/a
• Steps to reproduce the issue: See below

Hi there. Got a bit of a complex question regarding DbMigrator that's had me stumped for a couple of days now. Would love some guidance.

Background: I want to run the DbMigrator exe as part of an Azure Devops release pipeline. I also want to use AD authentication to authenticate the connection to the database as I don't want to have to have the SQL admin password in the connection string. As such, I'm running the exe in an Azure Powershell task. When I ran the exe in a Command Prompt task using SQL auth (with admin password in connection string) it worked fine.

Issue: When I attempt to run the exe in an Azure Powershell task, the migrator appears to run and then quit out straight after. There don't appear to be any errors though, nothing is written to the console and the Logs.txt file has nothing written to it.

To recreate this behaviour, I tried creating a Powershell script on my local machine to run the migrator. See below:

$filePath = 'C:\path_to_project\MyProject.DbMigrator\bin\Debug\net8.0\MyProject.DbMigrator.exe'
$proc = Start-Process $filePath -PassThru
$proc | Wait-Process

I saw the same behaviour: console window opens and then immediately closes, no logs written to Logs.txt or visible output from the app.

I put some Console.WriteLine and Task.Delay calls in the code of the migrator app and it then did start outputting stuff. It seems that the line that fails is in DbMigratorHostedService where the call await application.InitializeAsync() is made. It seems to basically just crash out the application at this point. I added a try catch block but no exception was raised.

I've put the customised code at the end of this message, but when running from Powershell, the last output I see is 44444444444444444444 (my debugging message) and then the console window closes.

It works totally fine using a command prompt. I see all my Console.WriteLines and it gets past that application.InitializeAsync part.

Question(s): Is it possible to run the DbMigrator from a Powershell script? Following on from that, is it possible to run it from an Azure Powershell task in an Azure DevOps CI/CD pipeline?

Alternatively: is there an alternative way I can run the migrator in my pipeline using AD authentication, meaning I can bypass this altogether?

DbMigratorHostedService.cs:

public class DbMigratorHostedService : IHostedService
{
    private readonly IHostApplicationLifetime _hostApplicationLifetime;
    private readonly IConfiguration _configuration;

    public DbMigratorHostedService(IHostApplicationLifetime hostApplicationLifetime, IConfiguration configuration)
    {
        _hostApplicationLifetime = hostApplicationLifetime;
        _configuration = configuration;
    }

    public async Task StartAsync(CancellationToken cancellationToken)
    {
	Console.WriteLine("33333333333333333333");
	await Task.Delay(2000);
	using (var application = await AbpApplicationFactory.CreateAsync<RopeManagementDbMigratorModule>(options =>
        {
           options.Services.ReplaceConfiguration(_configuration);
           options.UseAutofac();
           options.Services.AddLogging(c => c.AddSerilog());
           options.AddDataMigrationEnvironment();
        }))
        {
	    Console.WriteLine("44444444444444444444");
	    await Task.Delay(2000);
            try { 
	        await application.InitializeAsync();
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.ToString());
            }

	    Console.WriteLine("55555555555555555555");
	    await Task.Delay(2000);
	    await application
                .ServiceProvider
                .GetRequiredService<RopeManagementDbMigrationService>()
                .MigrateAsync();

	    Console.WriteLine("6666666666666666666");
	    await Task.Delay(2000);
	    await application.ShutdownAsync();

            _hostApplicationLifetime.StopApplication();
        }
    }

    public Task StopAsync(CancellationToken cancellationToken)
    {
        return Task.CompletedTask;
    }
}

• ABP Framework version: v7.4.2
• UI Type: MVC
• Database System: EF Core (PostgreSQL)

Hi. We are looking to understand how you decide to upgrade packages and when you choose to stick to certain versions.

A specific scenario we have right now is that we are currently seeing a critical issue reported by our SCA tool (mend.io) in the uppy.js dependency. ABP.io is currently using 1.X of uppy and are two major versions behind. https://www.mend.io/vulnerability-database/CVE-2022-0086

Is uppy on a backlog list somewhere to be updated? Have you chosen not to upgrade this for a reason? I understand we could upgrade try and upgrade this ourselves but there would be a high likelihood of breaking changes that we would then need to resolve.

Any help here would be appreciated. Thank you