For now we try to use a workaround - It would be really helpful for us if this would be implemented into the code in the future.

Hi @atripp,

thanks for the explanation.
I can understand that you are not willing/able to change this behavior. Now I will check if it is possible for us to modify the underlying wget call to allow downloading of the files from ProGet.

Best regards

Hi @atripp,
thanks for your fast answer.

Our script only downloads files from the ProGet-Server with wget on Linux and username:password (cannot be changed as simple). As we are using the API-Keys to authenticate with the server, so the wget call is the following:

wget --user api --password <api-key> <Download path>

After running this command I get a 401 from the Server. If I add the --auth-no-challenge argument like in the following snipped:

wget --user api --password <api-key> --auth-no-challenge <Download path>

than the Download runs without any issues.

The download also works without the --auth-no-challenge argument if I allow the download for Anonymous users.

I also checked if a download works if I send the Auth-Header manually with wget.

# generate base64 Encode Credentials
echo -n 'api:<key>' | base64

wget --header="Authorization: Basic <base64 Credentials>" <Download path>

This works also without any issues.

Hi there,
today I want to implement a file download over a toolkit which we use in our development process. This toolkit (which runs on linux) will download files from the server (now ProGet) over wget. The username and password will be used from wget over a .netrc file.

If I run a download of a file (I tested asset download and pypi-package download) with wget the ProGet-Server will response with 401 Unauthorized.

---response end---
401 Unauthorized
Registered socket 3 for persistent reuse.
Skipping 105 bytes of body: [You are not authorized to perform the Feeds_DownloadPackage task on this feed anonymously. Please log in.] done.
Unknown authentication scheme.

Username/Password Authentication Failed.

If I add the argument --auth-no-challenge to the wget call than the download will finish successfully but I this is more a workaround for this issue. As a side note the download of the same file over curl run without any issues and without extra arguments.

Are there any possibilities to fix this issue?

Best regards.

Would using an external database resolve that issue? So not using the embedded one?

Is it possible to switch to an external one with the instance already running with the embedded one?

Hi @atripp
thanks for your response and the description. We want to store some cache informations generated from yocto, onto our ProGet-Asset to share it between the developers. Unfortunately the generated filename can not be shorted, but it seems so that the maximum length of the filenames generated by yocto are 254.
Do you think it could be possible to modify the code/database to allow fitting this maximum?

Thanks

@Dan_Woolf Thanks for the quick reply - so this is nothing we can configure at the moment?

When uploading we do get the following error:

Failed to upload sstate:go-cross-canadian-aarch64:x86_64-nativesdk-poky-linux:1.17.13:r0:x86_64_x86_64-nativesdk:10:014a9fde37c442d487899c82c313f81e6bb015b8eaddfd10b257fda1e3e88afb_deploy_source_date_epoch.tar.zst.sigi: 22001: value too long for type character varying(200)

Npgsql.PostgresException (0x80004005): 22001: value too long for type character varying(200)
   at Npgsql.Internal.NpgsqlConnector.ReadMessageLong(Boolean async, DataRowLoadingMode dataRowLoadingMode, Boolean readingNotifications, Boolean isReadingPrependedMessage)
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
   at Npgsql.NpgsqlDataReader.NextResult(Boolean async, Boolean isConsuming, CancellationToken cancellationToken)
   at Npgsql.NpgsqlDataReader.NextResult(Boolean async, Boolean isConsuming, CancellationToken cancellationToken)
   at Npgsql.NpgsqlCommand.ExecuteReader(Boolean async, CommandBehavior behavior, CancellationToken cancellationToken)
   at Npgsql.NpgsqlCommand.ExecuteReader(Boolean async, CommandBehavior behavior, CancellationToken cancellationToken)
   at Inedo.ProGet.Data.PostgresDatabaseContext.PostgresCommand.ExecuteReaderAsync(CancellationToken cancellationToken) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\Data\PostgresDatabaseContext.cs:line 392
   at Inedo.Data.DatabaseContext.DbResult.CreateAsync(IGenericDbCommand command, DatabaseContext context, DateTimeOffset startTime, Stopwatch stopwatch)
   at Inedo.Data.DatabaseContext.ExecuteInternalAsync(String storedProcName, GenericDbParameter[] parameters, DatabaseCommandReturnType returnType)
   at Inedo.Data.DatabaseContext.ExecuteNonQueryAsync(String storedProcName, GenericDbParameter[] parameters)
   at Inedo.Data.DatabaseContext.ExecuteScalarAsync[TResult](String storedProcName, GenericDbParameter[] parameters, Int32 outParameterIndex)
   at Inedo.ProGet.Feeds.Assets.AssetFeed.AddExistingFileAsync(String fullPath, String contentType) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\Feeds\Assets\AssetFeed.cs:line 159
   at Inedo.ProGet.WebApplication.FeedEndpoints.Assets.AssetContentHandler.CompleteMultipartUploadAsync(AhHttpContext context, AssetFeed feed, String url, Boolean ignoreContentType) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\WebApplication\FeedEndpoints\Assets\AssetContentHandler.cs:line 318
   at Inedo.ProGet.WebApplication.FeedEndpoints.Assets.AssetContentHandler.UploadFileAsync(AhHttpContext context, WebApiContext apiContext, AssetFeed feed, String url, PutMode mode, Boolean ignoreContentType) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\WebApplication\FeedEndpoints\Assets\AssetContentHandler.cs:line 170
   at Inedo.ProGet.WebApplication.FeedEndpoints.Assets.AssetFineUploadHandler.TryProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, AssetFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\WebApplication\FeedEndpoints\Assets\AssetFineUploaderHandler.cs:line 29
  Exception data:
    Severity: ERROR
    SqlState: 22001
    MessageText: value too long for type character varying(200)
    Where: PL/pgSQL function "Assets_FindFromPath"(integer,text,boolean,boolean,integer,text,xml) line 18 at assignment
SQL statement "SELECT found."@AssetItem_Id",
           found."@CanonicalAssetPath_Text",
           found."@Inherited_CacheConfiguration_XML"
                                                                                                                        FROM "Assets_FindFromPath" (
            "@Feed_Id",
            "@AssetPath_Text",
            "@IncludeDeleted_Indicator",
            "@AllowCaseInsensitiveMatch_Indicator",
            "@AssetItem_Id",
            "@CanonicalAssetPath_Text",
            "@Inherited_CacheConfiguration_XML"
            ) AS found"
PL/pgSQL function "Assets_GetItemFromPath"(integer,text,boolean,boolean,text,xml,xml) line 6 at SQL statement
    File: varchar.c
    Line: 637
    Routine: varchar

::Asset Upload Error on 01/14/2026 10:02:19::

Anyone able to help on this?

Hi @stevedennis,

thanks for your reply, it would be really nice if this feature could be implemented. We would chat about this with our point of contact.

Thanks,
Florian

Hi there,

are there any possibilities to promote a package (internal feed) to next feed if the build is promoted?

The reason for this question is that my idea for a good workflow would be as followed:

• Developer commit changes in VCS
• CI-System builds and
  • upload package to feed universal-build
  • creates new build in proGet with previously uploaded package in state Build
• If the package will be tested the test-engineer could promote the build to state Test
  • now it would be nice if the packages (possible configurable) also would be promoted to another feed

Actually we should start a lookup for each package in the Package in the Build after promotion and should promote each Package manually (over Web-UI or pgutil-CLI) to another feed.

Would this be a possible workflow solution or there any other suggestions to work with package/build/promotion?

Best regards,
Florian